Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1279978 > unrolled thread

[PATCH v2 00/16] intel-lpss: support non-ACPI platforms

Started byAndy Shevchenko <andriy.shevchenko@linux.intel.com>
First post2015-11-30 16:20 +0100
Last post2015-12-07 02:20 +0100
Articles 17 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2 00/16] intel-lpss: support non-ACPI platforms Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 11/16] driver core: Do not overwrite secondary fwnode with NULL if it is set Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 03/16] device property: refactor built-in properties support Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 12/16] mfd: core: propagate device properties to sub devices drivers Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 01/16] device property: always check for fwnode type Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 16/16] i2c: designware: Convert to use unified device property API Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
      Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Wolfram Sang <wsa@the-dreams.de> - 2015-11-30 21:00 +0100
        Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Mika Westerberg <mika.westerberg@linux.intel.com> - 2015-12-01 10:10 +0100
        Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-01 11:40 +0100
          Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-12-02 02:00 +0100
            Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-12-02 10:30 +0100
              Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Mika Westerberg <mika.westerberg@linux.intel.com> - 2015-12-02 10:40 +0100
                Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device  property API Wolfram Sang <wsa@the-dreams.de> - 2015-12-02 11:00 +0100
    [PATCH v2 14/16] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 15/16] mfd: intel-lpss: Pass HSUART configuration via properties Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    [PATCH v2 13/16] mfd: intel-lpss: Add support for passing device properties Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2015-11-30 16:20 +0100
    Re: [PATCH v2 00/16] intel-lpss: support non-ACPI platforms "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-12-07 02:20 +0100

#1279978 — [PATCH v2 00/16] intel-lpss: support non-ACPI platforms

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 00/16] intel-lpss: support non-ACPI platforms
Message-ID<qAypb-5id-3@gated-at.bofh.it>
This series includes few logical sets that bring a support of non-ACPI
platforms for Intel Skylake.

First part is a refactoring of built-in device properties support:
- keep single value inside the structure
- provide helper macros to define built-in properties
- fall back to secondary fwnode if primary has no asked property

Second is a propagating built-in device properties in platform core.

Third one is modifications to MFD code and intel-lpss.c driver in particular
to define and pass built-in properties to the individual drivers.

And last part is a fix for I2C bug found on Lenovo Yoga hardware and a first
converted user.

Built-in device properties is an alternative to platform data. It provides a
unified API that drivers can use to cover all cases at once: DT, ACPI, and
built-in properties.

With this series applied a platform data can be considered obsolete. Moreover,
built-in device properties allow to adjust the existing configuration, for
example, in cases when ACPI values are wrong on some platforms.

The series has been tested on available hardware and doesn't break current
behaviour. But we ask people who have the affected hardware to apply the series
on your side and check with Lenovo hardware.

Changelog v2:
- fix isuues found by kbuild bot (kbuild)
- append a patch to propagate device properties in polatform code (Arnd)
- update few existing and add couple of new patches due to above
- check with kmemleak

Andy Shevchenko (9):
  device property: always check for fwnode type
  device property: rename helper functions
  device property: refactor built-in properties support
  device property: keep single value inplace
  device property: improve readability of macros
  device property: return -EINVAL when property isn't found in ACPI
  device property: Fallback to secondary fwnode if primary misses the
    property
  mfd: core: propagate device properties to sub devices drivers
  mfd: intel-lpss: Pass HSUART configuration via properties

Heikki Krogerus (1):
  device property: helper macros for property entry creation

Mika Westerberg (6):
  device property: Take a copy of the property set
  driver core: platform: Add support for built-in device properties
  driver core: Do not overwrite secondary fwnode with NULL if it is set
  mfd: intel-lpss: Add support for passing device properties
  mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
  i2c: designware: Convert to use unified device property API

 drivers/acpi/property.c                     |  10 +-
 drivers/base/core.c                         |   5 +-
 drivers/base/platform.c                     |  25 ++
 drivers/base/property.c                     | 491 ++++++++++++++++++++++------
 drivers/i2c/busses/i2c-designware-platdrv.c |  50 ++-
 drivers/mfd/intel-lpss-acpi.c               |  19 +-
 drivers/mfd/intel-lpss-pci.c                |  44 ++-
 drivers/mfd/intel-lpss.c                    |  16 +-
 drivers/mfd/intel-lpss.h                    |   2 +
 drivers/mfd/mfd-core.c                      |   7 +
 include/linux/mfd/core.h                    |   5 +
 include/linux/platform_device.h             |   5 +
 include/linux/property.h                    |  99 +++++-
 13 files changed, 621 insertions(+), 157 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1279981 — [PATCH v2 11/16] driver core: Do not overwrite secondary fwnode with NULL if it is set

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 11/16] driver core: Do not overwrite secondary fwnode with NULL if it is set
Message-ID<qAypc-5id-35@gated-at.bofh.it>
In reply to#1279978
From: Mika Westerberg <mika.westerberg@linux.intel.com>

If multiple devices share single firmware node like it is case with MFD
devices, the same firmware node (ACPI) is assigned to all of them. The
function also modifies the shared firmware node in order to preserve
secondary firmware node of the device in question.

If the new device which is sharing the firmware node does not have
secondary node it will be NULL which will be assigned to the secondary node
of the shared firmware node losing all built-in properties.

Prevent this by setting the secondary firmware node only if the replacement
is non-NULL.

Print also warning if someone tries to overwrite secondary node that has
already been assigned.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/base/core.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index b7d56c5..0a8bdad 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2261,7 +2261,10 @@ void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode)
 		if (fwnode_is_primary(fn))
 			fn = fn->secondary;
 
-		fwnode->secondary = fn;
+		if (fn) {
+			WARN_ON(fwnode->secondary);
+			fwnode->secondary = fn;
+		}
 		dev->fwnode = fwnode;
 	} else {
 		dev->fwnode = fwnode_is_primary(dev->fwnode) ?
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279985 — [PATCH v2 03/16] device property: refactor built-in properties support

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 03/16] device property: refactor built-in properties support
Message-ID<qAypd-5id-43@gated-at.bofh.it>
In reply to#1279978
Instead of using the type and nval fields we will use length (in bytes) of the
value. The sanity check is done in the accessors.

The built-in property accessors are split in the same way such as device tree.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/base/property.c  | 150 ++++++++++++++++++++++++++++++++++-------------
 include/linux/property.h |   8 +--
 2 files changed, 113 insertions(+), 45 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 2e01f3f..86834bd 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -63,45 +63,107 @@ static struct property_entry *pset_prop_get(struct property_set *pset,
 	return NULL;
 }
 
-static int pset_prop_read_array(struct property_set *pset, const char *name,
-				enum dev_prop_type type, void *val, size_t nval)
+static void *pset_prop_find(struct property_set *pset, const char *propname,
+			    size_t length)
 {
 	struct property_entry *prop;
-	unsigned int item_size;
+	void *pointer;
 
-	prop = pset_prop_get(pset, name);
+	prop = pset_prop_get(pset, propname);
+	if (!prop)
+		return ERR_PTR(-EINVAL);
+	pointer = prop->value.raw_data;
+	if (!pointer)
+		return ERR_PTR(-ENODATA);
+	if (length > prop->length)
+		return ERR_PTR(-EOVERFLOW);
+	return pointer;
+}
+
+static int pset_prop_read_u8_array(struct property_set *pset,
+				   const char *propname,
+				   u8 *values, size_t nval)
+{
+	void *pointer;
+	size_t length = nval * sizeof(*values);
+
+	pointer = pset_prop_find(pset, propname, length);
+	if (IS_ERR(pointer))
+		return PTR_ERR(pointer);
+
+	memcpy(values, pointer, length);
+	return 0;
+}
+
+static int pset_prop_read_u16_array(struct property_set *pset,
+				    const char *propname,
+				    u16 *values, size_t nval)
+{
+	void *pointer;
+	size_t length = nval * sizeof(*values);
+
+	pointer = pset_prop_find(pset, propname, length);
+	if (IS_ERR(pointer))
+		return PTR_ERR(pointer);
+
+	memcpy(values, pointer, length);
+	return 0;
+}
+
+static int pset_prop_read_u32_array(struct property_set *pset,
+				    const char *propname,
+				    u32 *values, size_t nval)
+{
+	void *pointer;
+	size_t length = nval * sizeof(*values);
+
+	pointer = pset_prop_find(pset, propname, length);
+	if (IS_ERR(pointer))
+		return PTR_ERR(pointer);
+
+	memcpy(values, pointer, length);
+	return 0;
+}
+
+static int pset_prop_read_u64_array(struct property_set *pset,
+				    const char *propname,
+				    u64 *values, size_t nval)
+{
+	void *pointer;
+	size_t length = nval * sizeof(*values);
+
+	pointer = pset_prop_find(pset, propname, length);
+	if (IS_ERR(pointer))
+		return PTR_ERR(pointer);
+
+	memcpy(values, pointer, length);
+	return 0;
+}
+
+static int pset_prop_count_elems_of_size(struct property_set *pset,
+					 const char *propname, size_t length)
+{
+	struct property_entry *prop;
+
+	prop = pset_prop_get(pset, propname);
 	if (!prop)
-		return -ENODATA;
-
-	if (prop->type != type)
-		return -EPROTO;
-
-	if (!val)
-		return prop->nval;
-
-	if (prop->nval < nval)
-		return -EOVERFLOW;
-
-	switch (type) {
-	case DEV_PROP_U8:
-		item_size = sizeof(u8);
-		break;
-	case DEV_PROP_U16:
-		item_size = sizeof(u16);
-		break;
-	case DEV_PROP_U32:
-		item_size = sizeof(u32);
-		break;
-	case DEV_PROP_U64:
-		item_size = sizeof(u64);
-		break;
-	case DEV_PROP_STRING:
-		item_size = sizeof(const char *);
-		break;
-	default:
 		return -EINVAL;
-	}
-	memcpy(val, prop->value.raw_data, nval * item_size);
+
+	return prop->length / length;
+}
+
+static int pset_prop_read_string_array(struct property_set *pset,
+				       const char *propname,
+				       const char **strings, size_t nval)
+{
+	void *pointer;
+	size_t length = nval * sizeof(*strings);
+
+	pointer = pset_prop_find(pset, propname, length);
+	if (IS_ERR(pointer))
+		return PTR_ERR(pointer);
+
+	memcpy(strings, pointer, length);
 	return 0;
 }
 
@@ -314,6 +376,10 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
 	(val) ? of_property_read_##type##_array((node), (propname), (val), (nval)) \
 	      : of_property_count_elems_of_size((node), (propname), sizeof(type))
 
+#define PSET_PROP_READ_ARRAY(node, propname, type, val, nval)				\
+	(val) ? pset_prop_read_##type##_array((node), (propname), (val), (nval))	\
+	      : pset_prop_count_elems_of_size((node), (propname), sizeof(type))
+
 #define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_, _val_, _nval_) \
 ({ \
 	int _ret_; \
@@ -324,8 +390,8 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
 		_ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_, \
 					    _val_, _nval_); \
 	else if (is_pset_node(_fwnode_)) 						\
-		_ret_ = pset_prop_read_array(to_pset_node(_fwnode_), _propname_,	\
-					     _proptype_, _val_, _nval_); \
+		_ret_ = PSET_PROP_READ_ARRAY(to_pset_node(_fwnode_), _propname_,	\
+					     _type_, _val_, _nval_);			\
 	else \
 		_ret_ = -ENXIO; \
 	_ret_; \
@@ -466,8 +532,12 @@ int fwnode_property_read_string_array(struct fwnode_handle *fwnode,
 		return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
 					   val, nval);
 	else if (is_pset_node(fwnode))
-		return pset_prop_read_array(to_pset_node(fwnode), propname,
-					    DEV_PROP_STRING, val, nval);
+		return val ?
+			pset_prop_read_string_array(to_pset_node(fwnode),
+						    propname, val, nval) :
+			pset_prop_count_elems_of_size(to_pset_node(fwnode),
+						      propname,
+						      sizeof(const char *));
 	return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string_array);
@@ -496,8 +566,8 @@ int fwnode_property_read_string(struct fwnode_handle *fwnode,
 		return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
 					   val, 1);
 	else if (is_pset_node(fwnode))
-		return pset_prop_read_array(to_pset_node(fwnode), propname,
-					    DEV_PROP_STRING, val, 1);
+		return pset_prop_read_string_array(to_pset_node(fwnode),
+						   propname, val, 1);
 	return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string);
diff --git a/include/linux/property.h b/include/linux/property.h
index 0a3705a..c29460a 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -144,14 +144,12 @@ static inline int fwnode_property_read_u64(struct fwnode_handle *fwnode,
 /**
  * struct property_entry - "Built-in" device property representation.
  * @name: Name of the property.
- * @type: Type of the property.
- * @nval: Number of items of type @type making up the value.
- * @value: Value of the property (an array of @nval items of type @type).
+ * @length: Length of data making up the value.
+ * @value: Value of the property (an array of items of the given type).
  */
 struct property_entry {
 	const char *name;
-	enum dev_prop_type type;
-	size_t nval;
+	size_t length;
 	union {
 		void *raw_data;
 		u8 *u8_data;
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279986 — [PATCH v2 12/16] mfd: core: propagate device properties to sub devices drivers

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 12/16] mfd: core: propagate device properties to sub devices drivers
Message-ID<qAypd-5id-49@gated-at.bofh.it>
In reply to#1279978
In the similar way like we do for the platform data we propagate the device
properties. For example, in case of Intel LPSS drivers we may provide a
specific property to tell the actual device driver an additional information
such as platform name.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/mfd/mfd-core.c   | 7 +++++++
 include/linux/mfd/core.h | 5 +++++
 2 files changed, 12 insertions(+)

diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 60b60dc..88bd1b1 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -14,6 +14,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/acpi.h>
+#include <linux/property.h>
 #include <linux/mfd/core.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
@@ -192,6 +193,12 @@ static int mfd_add_device(struct device *parent, int id,
 			goto fail_alias;
 	}
 
+	if (cell->pset) {
+		ret = platform_device_add_properties(pdev, cell->pset);
+		if (ret)
+			goto fail_alias;
+	}
+
 	ret = mfd_platform_add_cell(pdev, cell, usage_count);
 	if (ret)
 		goto fail_alias;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 27dac3f..bc6f7e0 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -17,6 +17,7 @@
 #include <linux/platform_device.h>
 
 struct irq_domain;
+struct property_set;
 
 /* Matches ACPI PNP id, either _HID or _CID, or ACPI _ADR */
 struct mfd_cell_acpi_match {
@@ -44,6 +45,10 @@ struct mfd_cell {
 	/* platform data passed to the sub devices drivers */
 	void			*platform_data;
 	size_t			pdata_size;
+
+	/* device properties passed to the sub devices drivers */
+	const struct property_set *pset;
+
 	/*
 	 * Device Tree compatible string
 	 * See: Documentation/devicetree/usage-model.txt Chapter 2.2 for details
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279987 — [PATCH v2 01/16] device property: always check for fwnode type

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 01/16] device property: always check for fwnode type
Message-ID<qAypd-5id-47@gated-at.bofh.it>
In reply to#1279978
Currently the property accessors unconditionally fall back to built-in property
set as a last resort. Make this strict and return an error in case the type of
fwnode is unknown.

This is actually a follow up to the commit 4fa7508e9f1c (device property:
Return -ENXIO if there is no suitable FW interface).

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/base/property.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 1325ff2..09e488d 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -135,8 +135,9 @@ bool fwnode_property_present(struct fwnode_handle *fwnode, const char *propname)
 		return of_property_read_bool(to_of_node(fwnode), propname);
 	else if (is_acpi_node(fwnode))
 		return !acpi_node_prop_get(fwnode, propname, NULL);
-
-	return !!pset_prop_get(to_pset(fwnode), propname);
+	else if (is_pset(fwnode))
+		return !!pset_prop_get(to_pset(fwnode), propname);
+	return false;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_present);
 
@@ -494,9 +495,10 @@ int fwnode_property_read_string(struct fwnode_handle *fwnode,
 	else if (is_acpi_node(fwnode))
 		return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
 					   val, 1);
-
-	return pset_prop_read_array(to_pset(fwnode), propname,
-				    DEV_PROP_STRING, val, 1);
+	else if (is_pset(fwnode))
+		return pset_prop_read_array(to_pset(fwnode), propname,
+					    DEV_PROP_STRING, val, 1);
+	return -ENXIO;
 }
 EXPORT_SYMBOL_GPL(fwnode_property_read_string);
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279988 — [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qAypd-5id-55@gated-at.bofh.it>
In reply to#1279978
From: Mika Westerberg <mika.westerberg@linux.intel.com>

With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device
configuration information from ACPI in addition to DT. In order to support
this, convert the driver to use the unified device property accessors
instead of DT specific.

Change to ordering a bit so that we first try platform data and if that's
not available look from device properties. ACPI *CNT methods are then used
as last resort to override everything else.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 50 +++++++++++++----------------
 1 file changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 809579e..06061b5 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -36,6 +36,7 @@
 #include <linux/platform_device.h>
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
+#include <linux/property.h>
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -129,10 +130,10 @@ static inline int dw_i2c_acpi_configure(struct platform_device *pdev)
 
 static int dw_i2c_plat_probe(struct platform_device *pdev)
 {
+	struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
 	struct dw_i2c_dev *dev;
 	struct i2c_adapter *adap;
 	struct resource *mem;
-	struct dw_i2c_platform_data *pdata;
 	int irq, r;
 	u32 clk_freq, ht = 0;
 
@@ -156,33 +157,28 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 	/* fast mode by default because of legacy reasons */
 	clk_freq = 400000;
 
-	if (has_acpi_companion(&pdev->dev)) {
-		dw_i2c_acpi_configure(pdev);
-	} else if (pdev->dev.of_node) {
-		of_property_read_u32(pdev->dev.of_node,
-					"i2c-sda-hold-time-ns", &ht);
-
-		of_property_read_u32(pdev->dev.of_node,
-				     "i2c-sda-falling-time-ns",
-				     &dev->sda_falling_time);
-		of_property_read_u32(pdev->dev.of_node,
-				     "i2c-scl-falling-time-ns",
-				     &dev->scl_falling_time);
-
-		of_property_read_u32(pdev->dev.of_node, "clock-frequency",
-				     &clk_freq);
-
-		/* Only standard mode at 100kHz and fast mode at 400kHz
-		 * are supported.
-		 */
-		if (clk_freq != 100000 && clk_freq != 400000) {
-			dev_err(&pdev->dev, "Only 100kHz and 400kHz supported");
-			return -EINVAL;
-		}
+	if (pdata) {
+		clk_freq = pdata->i2c_scl_freq;
 	} else {
-		pdata = dev_get_platdata(&pdev->dev);
-		if (pdata)
-			clk_freq = pdata->i2c_scl_freq;
+		device_property_read_u32(&pdev->dev, "i2c-sda-hold-time-ns",
+					 &ht);
+		device_property_read_u32(&pdev->dev, "i2c-sda-falling-time-ns",
+					 &dev->sda_falling_time);
+		device_property_read_u32(&pdev->dev, "i2c-scl-falling-time-ns",
+					 &dev->scl_falling_time);
+		device_property_read_u32(&pdev->dev, "clock-frequency",
+					 &clk_freq);
+	}
+
+	if (has_acpi_companion(&pdev->dev))
+		dw_i2c_acpi_configure(pdev);
+
+	/*
+	 * Only standard mode at 100kHz and fast mode at 400kHz are supported.
+	 */
+	if (clk_freq != 100000 && clk_freq != 400000) {
+		dev_err(&pdev->dev, "Only 100kHz and 400kHz supported");
+		return -EINVAL;
 	}
 
 	r = i2c_dw_eval_lock_support(dev);
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1280237 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromWolfram Sang <wsa@the-dreams.de>
Date2015-11-30 21:00 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qACMa-7Uc-21@gated-at.bofh.it>
In reply to#1279988

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> 
> With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device
> configuration information from ACPI in addition to DT. In order to support
> this, convert the driver to use the unified device property accessors
> instead of DT specific.
> 
> Change to ordering a bit so that we first try platform data and if that's
> not available look from device properties. ACPI *CNT methods are then used
> as last resort to override everything else.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>

What is the bug fix here described in the cover letter?

And shall this go via I2C or via the rest of the series?

> ---
>  drivers/i2c/busses/i2c-designware-platdrv.c | 50 +++++++++++++----------------
>  1 file changed, 23 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 809579e..06061b5 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -36,6 +36,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/pm.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/property.h>
>  #include <linux/io.h>
>  #include <linux/slab.h>
>  #include <linux/acpi.h>
> @@ -129,10 +130,10 @@ static inline int dw_i2c_acpi_configure(struct platform_device *pdev)
>  
>  static int dw_i2c_plat_probe(struct platform_device *pdev)
>  {
> +	struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
>  	struct dw_i2c_dev *dev;
>  	struct i2c_adapter *adap;
>  	struct resource *mem;
> -	struct dw_i2c_platform_data *pdata;
>  	int irq, r;
>  	u32 clk_freq, ht = 0;
>  
> @@ -156,33 +157,28 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
>  	/* fast mode by default because of legacy reasons */
>  	clk_freq = 400000;
>  
> -	if (has_acpi_companion(&pdev->dev)) {
> -		dw_i2c_acpi_configure(pdev);
> -	} else if (pdev->dev.of_node) {
> -		of_property_read_u32(pdev->dev.of_node,
> -					"i2c-sda-hold-time-ns", &ht);
> -
> -		of_property_read_u32(pdev->dev.of_node,
> -				     "i2c-sda-falling-time-ns",
> -				     &dev->sda_falling_time);
> -		of_property_read_u32(pdev->dev.of_node,
> -				     "i2c-scl-falling-time-ns",
> -				     &dev->scl_falling_time);
> -
> -		of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> -				     &clk_freq);
> -
> -		/* Only standard mode at 100kHz and fast mode at 400kHz
> -		 * are supported.
> -		 */
> -		if (clk_freq != 100000 && clk_freq != 400000) {
> -			dev_err(&pdev->dev, "Only 100kHz and 400kHz supported");
> -			return -EINVAL;
> -		}
> +	if (pdata) {
> +		clk_freq = pdata->i2c_scl_freq;
>  	} else {
> -		pdata = dev_get_platdata(&pdev->dev);
> -		if (pdata)
> -			clk_freq = pdata->i2c_scl_freq;
> +		device_property_read_u32(&pdev->dev, "i2c-sda-hold-time-ns",
> +					 &ht);
> +		device_property_read_u32(&pdev->dev, "i2c-sda-falling-time-ns",
> +					 &dev->sda_falling_time);
> +		device_property_read_u32(&pdev->dev, "i2c-scl-falling-time-ns",
> +					 &dev->scl_falling_time);
> +		device_property_read_u32(&pdev->dev, "clock-frequency",
> +					 &clk_freq);
> +	}
> +
> +	if (has_acpi_companion(&pdev->dev))
> +		dw_i2c_acpi_configure(pdev);
> +
> +	/*
> +	 * Only standard mode at 100kHz and fast mode at 400kHz are supported.
> +	 */
> +	if (clk_freq != 100000 && clk_freq != 400000) {
> +		dev_err(&pdev->dev, "Only 100kHz and 400kHz supported");
> +		return -EINVAL;
>  	}
>  
>  	r = i2c_dw_eval_lock_support(dev);
> -- 
> 2.6.2
> 

[toc] | [prev] | [next] | [standalone]


#1280660 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2015-12-01 10:10 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qAP6G-7EK-5@gated-at.bofh.it>
In reply to#1280237
On Mon, Nov 30, 2015 at 08:58:58PM +0100, Wolfram Sang wrote:
> On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > 
> > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device
> > configuration information from ACPI in addition to DT. In order to support
> > this, convert the driver to use the unified device property accessors
> > instead of DT specific.
> > 
> > Change to ordering a bit so that we first try platform data and if that's
> > not available look from device properties. ACPI *CNT methods are then used
> > as last resort to override everything else.
> > 
> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> 
> What is the bug fix here described in the cover letter?

The bug fix is actually in patch [14/16] "mfd: intel-lpss: Pass SDA hold
time to I2C host controller driver".

> And shall this go via I2C or via the rest of the series?

Either way works. This should compile and work fine without the rest but
of course fix for the issue with Lenovo Yoga 900 toucpad still requires
all the patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1280738 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-12-01 11:40 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qAQvL-8pk-9@gated-at.bofh.it>
In reply to#1280237
On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote:
> On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > 
> > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass
> > device
> > configuration information from ACPI in addition to DT. In order to
> > support
> > this, convert the driver to use the unified device property
> > accessors
> > instead of DT specific.
> > 
> > Change to ordering a bit so that we first try platform data and if
> > that's
> > not available look from device properties. ACPI *CNT methods are
> > then used
> > as last resort to override everything else.
> > 
> > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> 
> What is the bug fix here described in the cover letter?

The cover letter mentioned 'last part' which I refer to as patches 14,
15 (though this is for UART), and 16.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1281380 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2015-12-02 02:00 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qB3W2-8uw-5@gated-at.bofh.it>
In reply to#1280738
On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote:
> On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote:
> > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> > > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > 
> > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass
> > > device
> > > configuration information from ACPI in addition to DT. In order to
> > > support
> > > this, convert the driver to use the unified device property
> > > accessors
> > > instead of DT specific.
> > > 
> > > Change to ordering a bit so that we first try platform data and if
> > > that's
> > > not available look from device properties. ACPI *CNT methods are
> > > then used
> > > as last resort to override everything else.
> > > 
> > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> > 
> > What is the bug fix here described in the cover letter?
> 
> The cover letter mentioned 'last part' which I refer to as patches 14,
> 15 (though this is for UART), and 16.

Hmm.

So may I assume that patches [1-13/16] are for me and the rest is to be applied
by the other respective maintainers?

That should be easiest logistically IMHO.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1281545 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-12-02 10:30 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qBbTB-5ig-31@gated-at.bofh.it>
In reply to#1281380
On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote:
> On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote:
> > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote:
> > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:



> > > What is the bug fix here described in the cover letter?
> > 
> > The cover letter mentioned 'last part' which I refer to as patches
> > 14,
> > 15 (though this is for UART), and 16.
> 
> Hmm.
> 
> So may I assume that patches [1-13/16] are for me and the rest is to
> be applied
> by the other respective maintainers?
> 
> That should be easiest logistically IMHO.

Have no objections.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1281561 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2015-12-02 10:40 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qBc3k-5mE-97@gated-at.bofh.it>
In reply to#1281545
On Wed, Dec 02, 2015 at 11:23:40AM +0200, Andy Shevchenko wrote:
> On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote:
> > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote:
> > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> 
> 
> 
> > > > What is the bug fix here described in the cover letter?
> > > 
> > > The cover letter mentioned 'last part' which I refer to as patches
> > > 14,
> > > 15 (though this is for UART), and 16.
> > 
> > Hmm.
> > 
> > So may I assume that patches [1-13/16] are for me and the rest is to
> > be applied
> > by the other respective maintainers?
> > 
> > That should be easiest logistically IMHO.
> 
> Have no objections.

Unfortunately the patches (except this one) depend on each other so they
cannot be applied separately.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1281570 — Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API

FromWolfram Sang <wsa@the-dreams.de>
Date2015-12-02 11:00 +0100
SubjectRe: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
Message-ID<qBcmB-5tS-13@gated-at.bofh.it>
In reply to#1281561

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 02, 2015 at 11:33:41AM +0200, Mika Westerberg wrote:
> On Wed, Dec 02, 2015 at 11:23:40AM +0200, Andy Shevchenko wrote:
> > On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote:
> > > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote:
> > > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote:
> > 
> > 
> > 
> > > > > What is the bug fix here described in the cover letter?
> > > > 
> > > > The cover letter mentioned 'last part' which I refer to as patches
> > > > 14,
> > > > 15 (though this is for UART), and 16.
> > > 
> > > Hmm.
> > > 
> > > So may I assume that patches [1-13/16] are for me and the rest is to
> > > be applied
> > > by the other respective maintainers?
> > > 
> > > That should be easiest logistically IMHO.
> > 
> > Have no objections.
> 
> Unfortunately the patches (except this one) depend on each other so they
> cannot be applied separately.

So, why not let all of them go in in one go?

For this patch:

Acked-by: Wolfram Sang <wsa@the-dreams.de>

[toc] | [prev] | [next] | [standalone]


#1279989 — [PATCH v2 14/16] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 14/16] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
Message-ID<qAypd-5id-51@gated-at.bofh.it>
In reply to#1279978
From: Mika Westerberg <mika.westerberg@linux.intel.com>

Intel Skylake the LPSS I2C pad circuit has internal delays that require
programming non-zero SDA hold time for the I2C host controller. If this is
not done communication to slave devices may fail with arbitration lost
errors like the one seen below taken from Lenovo Yoga 900:

  i2c_hid i2c-SYNA2B29:00: Fetching the HID descriptor
  i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=20 00
  i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration

To fix this we follow what the Windows driver is doing and pass the default
SDA hold time of 230 ns to all Intel Skylake host controllers. This still
allows the platform to override these values by passing special ACPI
methods SSCN and FMCN.

Reported-by: Kevin Fenzi <kevin@scrye.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/mfd/intel-lpss-acpi.c | 19 +++++++++++++++++--
 drivers/mfd/intel-lpss-pci.c  | 31 +++++++++++++++++++++++--------
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index b6fd904..06f00d6 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -18,6 +18,7 @@
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
 
 #include "intel-lpss.h"
 
@@ -25,6 +26,20 @@ static const struct intel_lpss_platform_info spt_info = {
 	.clk_rate = 120000000,
 };
 
+static struct property_entry spt_i2c_properties[] = {
+	PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+	{ },
+};
+
+static struct property_set spt_i2c_pset = {
+	.properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+	.clk_rate = 120000000,
+	.pset = &spt_i2c_pset,
+};
+
 static const struct intel_lpss_platform_info bxt_info = {
 	.clk_rate = 100000000,
 };
@@ -35,8 +50,8 @@ static const struct intel_lpss_platform_info bxt_i2c_info = {
 
 static const struct acpi_device_id intel_lpss_acpi_ids[] = {
 	/* SPT */
-	{ "INT3446", (kernel_ulong_t)&spt_info },
-	{ "INT3447", (kernel_ulong_t)&spt_info },
+	{ "INT3446", (kernel_ulong_t)&spt_i2c_info },
+	{ "INT3447", (kernel_ulong_t)&spt_i2c_info },
 	/* BXT */
 	{ "80860AAC", (kernel_ulong_t)&bxt_i2c_info },
 	{ "80860ABC", (kernel_ulong_t)&bxt_info },
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 5bfdfcc..a677480 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -17,6 +17,7 @@
 #include <linux/pci.h>
 #include <linux/pm.h>
 #include <linux/pm_runtime.h>
+#include <linux/property.h>
 
 #include "intel-lpss.h"
 
@@ -65,6 +66,20 @@ static const struct intel_lpss_platform_info spt_info = {
 	.clk_rate = 120000000,
 };
 
+static struct property_entry spt_i2c_properties[] = {
+	PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+	{ },
+};
+
+static struct property_set spt_i2c_pset = {
+	.properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+	.clk_rate = 120000000,
+	.pset = &spt_i2c_pset,
+};
+
 static const struct intel_lpss_platform_info spt_uart_info = {
 	.clk_rate = 120000000,
 	.clk_con_id = "baudclk",
@@ -121,20 +136,20 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
 	{ PCI_VDEVICE(INTEL, 0x9d28), (kernel_ulong_t)&spt_uart_info },
 	{ PCI_VDEVICE(INTEL, 0x9d29), (kernel_ulong_t)&spt_info },
 	{ PCI_VDEVICE(INTEL, 0x9d2a), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)&spt_info },
+	{ PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)&spt_i2c_info },
 	{ PCI_VDEVICE(INTEL, 0x9d66), (kernel_ulong_t)&spt_uart_info },
 	/* SPT-H */
 	{ PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)&spt_uart_info },
 	{ PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)&spt_uart_info },
 	{ PCI_VDEVICE(INTEL, 0xa129), (kernel_ulong_t)&spt_info },
 	{ PCI_VDEVICE(INTEL, 0xa12a), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t)&spt_info },
-	{ PCI_VDEVICE(INTEL, 0xa161), (kernel_ulong_t)&spt_info },
+	{ PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t)&spt_i2c_info },
+	{ PCI_VDEVICE(INTEL, 0xa161), (kernel_ulong_t)&spt_i2c_info },
 	{ PCI_VDEVICE(INTEL, 0xa166), (kernel_ulong_t)&spt_uart_info },
 	{ }
 };
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279992 — [PATCH v2 15/16] mfd: intel-lpss: Pass HSUART configuration via properties

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 15/16] mfd: intel-lpss: Pass HSUART configuration via properties
Message-ID<qAype-5id-65@gated-at.bofh.it>
In reply to#1279978
The HS-UART host controller driver needs to know certain properties like
width of the register set if it cannot get that information from ACPI or
DT. In order to support non-ACPI systems we pass this information to the
driver via device properties.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/mfd/intel-lpss-pci.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index a677480..a7136c7 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -80,9 +80,21 @@ static const struct intel_lpss_platform_info spt_i2c_info = {
 	.pset = &spt_i2c_pset,
 };
 
+static struct property_entry uart_properties[] = {
+	PROPERTY_ENTRY_U32("reg-io-width", 4),
+	PROPERTY_ENTRY_U32("reg-shift", 2),
+	PROPERTY_ENTRY_BOOL("snps,uart-16550-compatible"),
+	{ },
+};
+
+static struct property_set uart_pset = {
+	.properties = uart_properties,
+};
+
 static const struct intel_lpss_platform_info spt_uart_info = {
 	.clk_rate = 120000000,
 	.clk_con_id = "baudclk",
+	.pset = &uart_pset,
 };
 
 static const struct intel_lpss_platform_info bxt_info = {
@@ -92,6 +104,7 @@ static const struct intel_lpss_platform_info bxt_info = {
 static const struct intel_lpss_platform_info bxt_uart_info = {
 	.clk_rate = 100000000,
 	.clk_con_id = "baudclk",
+	.pset = &uart_pset,
 };
 
 static const struct intel_lpss_platform_info bxt_i2c_info = {
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1279993 — [PATCH v2 13/16] mfd: intel-lpss: Add support for passing device properties

FromAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Date2015-11-30 16:20 +0100
Subject[PATCH v2 13/16] mfd: intel-lpss: Add support for passing device properties
Message-ID<qAypd-5id-59@gated-at.bofh.it>
In reply to#1279978
From: Mika Westerberg <mika.westerberg@linux.intel.com>

If the boot firmware does not support ACPI we need a way to pass device
configuration information to the drivers. The unified device properties API
already supports passing platform data via properties so let's take
advantage of that and allow probe drivers to pass set of properties to the
host controller driver.

In order to do that we need to be able to modify the MFD cell corresponding
the host controller, so make the core driver to take copy of the cell
instead of using it directly. Then we can assign info->pset to the
resulting copy of a cell and let the MFD core to assign that to the
resulting device.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/mfd/intel-lpss.c | 16 ++++++++++++----
 drivers/mfd/intel-lpss.h |  2 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 6255513..1743788 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -24,6 +24,7 @@
 #include <linux/mfd/core.h>
 #include <linux/pm_qos.h>
 #include <linux/pm_runtime.h>
+#include <linux/property.h>
 #include <linux/seq_file.h>
 #include <linux/io-64-nonatomic-lo-hi.h>
 
@@ -72,7 +73,7 @@ struct intel_lpss {
 	enum intel_lpss_dev_type type;
 	struct clk *clk;
 	struct clk_lookup *clock;
-	const struct mfd_cell *cell;
+	struct mfd_cell *cell;
 	struct device *dev;
 	void __iomem *priv;
 	int devid;
@@ -217,6 +218,7 @@ static void intel_lpss_ltr_hide(struct intel_lpss *lpss)
 
 static int intel_lpss_assign_devs(struct intel_lpss *lpss)
 {
+	const struct mfd_cell *cell;
 	unsigned int type;
 
 	type = lpss->caps & LPSS_PRIV_CAPS_TYPE_MASK;
@@ -224,18 +226,22 @@ static int intel_lpss_assign_devs(struct intel_lpss *lpss)
 
 	switch (type) {
 	case LPSS_DEV_I2C:
-		lpss->cell = &intel_lpss_i2c_cell;
+		cell = &intel_lpss_i2c_cell;
 		break;
 	case LPSS_DEV_UART:
-		lpss->cell = &intel_lpss_uart_cell;
+		cell = &intel_lpss_uart_cell;
 		break;
 	case LPSS_DEV_SPI:
-		lpss->cell = &intel_lpss_spi_cell;
+		cell = &intel_lpss_spi_cell;
 		break;
 	default:
 		return -ENODEV;
 	}
 
+	lpss->cell = devm_kmemdup(lpss->dev, cell, sizeof(*cell), GFP_KERNEL);
+	if (!lpss->cell)
+		return -ENOMEM;
+
 	lpss->type = type;
 
 	return 0;
@@ -401,6 +407,8 @@ int intel_lpss_probe(struct device *dev,
 	if (ret)
 		return ret;
 
+	lpss->cell->pset = info->pset;
+
 	intel_lpss_init_dev(lpss);
 
 	lpss->devid = ida_simple_get(&intel_lpss_devid_ida, 0, 0, GFP_KERNEL);
diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
index 2c7f8d7..0dcea9e 100644
--- a/drivers/mfd/intel-lpss.h
+++ b/drivers/mfd/intel-lpss.h
@@ -16,12 +16,14 @@
 
 struct device;
 struct resource;
+struct property_set;
 
 struct intel_lpss_platform_info {
 	struct resource *mem;
 	int irq;
 	unsigned long clk_rate;
 	const char *clk_con_id;
+	struct property_set *pset;
 };
 
 int intel_lpss_probe(struct device *dev,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1284953

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2015-12-07 02:20 +0100
Message-ID<qCSD7-699-5@gated-at.bofh.it>
In reply to#1279978
On Monday, November 30, 2015 05:11:28 PM Andy Shevchenko wrote:
> This series includes few logical sets that bring a support of non-ACPI
> platforms for Intel Skylake.
> 
> First part is a refactoring of built-in device properties support:
> - keep single value inside the structure
> - provide helper macros to define built-in properties
> - fall back to secondary fwnode if primary has no asked property
> 
> Second is a propagating built-in device properties in platform core.
> 
> Third one is modifications to MFD code and intel-lpss.c driver in particular
> to define and pass built-in properties to the individual drivers.
> 
> And last part is a fix for I2C bug found on Lenovo Yoga hardware and a first
> converted user.
> 
> Built-in device properties is an alternative to platform data. It provides a
> unified API that drivers can use to cover all cases at once: DT, ACPI, and
> built-in properties.
> 
> With this series applied a platform data can be considered obsolete. Moreover,
> built-in device properties allow to adjust the existing configuration, for
> example, in cases when ACPI values are wrong on some platforms.
> 
> The series has been tested on available hardware and doesn't break current
> behaviour. But we ask people who have the affected hardware to apply the series
> on your side and check with Lenovo hardware.
> 
> Changelog v2:
> - fix isuues found by kbuild bot (kbuild)
> - append a patch to propagate device properties in polatform code (Arnd)
> - update few existing and add couple of new patches due to above
> - check with kmemleak
> 
> Andy Shevchenko (9):
>   device property: always check for fwnode type
>   device property: rename helper functions
>   device property: refactor built-in properties support
>   device property: keep single value inplace
>   device property: improve readability of macros
>   device property: return -EINVAL when property isn't found in ACPI
>   device property: Fallback to secondary fwnode if primary misses the
>     property
>   mfd: core: propagate device properties to sub devices drivers
>   mfd: intel-lpss: Pass HSUART configuration via properties
> 
> Heikki Krogerus (1):
>   device property: helper macros for property entry creation
> 
> Mika Westerberg (6):
>   device property: Take a copy of the property set
>   driver core: platform: Add support for built-in device properties
>   driver core: Do not overwrite secondary fwnode with NULL if it is set
>   mfd: intel-lpss: Add support for passing device properties
>   mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
>   i2c: designware: Convert to use unified device property API

I'm going to queue up this series for v4.5.

If there are any problems with it or objections from anyone, please let me know.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web