[PATCH v7 0/6] Add ChromeOS EC CEC Support

[PATCH v7 0/6] Add ChromeOS EC CEC Support

[Neil Armstrong]

Hi All,

The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device registration in the ChromeOS EC MFD Driver
- Add the CEC related commands and events definitions into the EC MFD driver
- Add a way to get a CEC notifier with it's (optional) connector name
- Add the CEC notifier to the i915 HDMI driver
- Add the proper ChromeOS EC CEC Driver

The CEC notifier with the connector name is the tricky point, since even on
Device-Tree platforms, there is no way to distinguish between multiple HDMI
connectors from the same DRM driver. The solution I implemented is pretty
simple and only adds an optional connector name to eventually distinguish
an HDMI connector notifier from another if they share the same device.

Feel free to comment this patchset !

Changes since v6:
- Added stable identifier comment in intel_display.h
- Renamed to cec_notifier in intel_hdmi.c/intel_drv.h
- Added Acked-by/Reviewed-By tags

Changes since v5:
 - Small fixups on include/linux/mfd/cros_ec_commands.h
 - Fixed on cros-ec-cec driver accordingly
 - Added Reviewed-By tags

Changes since v4:
 - Split patch 3 to move the mkbp event size change into a separate patch

Changes since v3 (incorrectly reported as v2):
 - Renamed "Chrome OS" to "ChromeOS"
 - Updated cros_ec_commands.h new structs definitions to kernel doc format
 - Added Reviewed-By tags

Changes since v2:
 - Add i915 port_identifier() and use this stable name as cec_notifier conn name
 - Fixed and cleaned up the CEC commands and events handling
 - Rebased the CEC sub-device registration on top of Enric's serie
 - Fixed comments typo on cec driver
 - Protected the DMI match only with PCI and DMI Kconfigs

Changes since v1:
 - Added cec_notifier_put to intel_hdmi
 - Fixed all small reported issues on the EC CEC driver
 - Moved the cec_notifier_get out of the #if .. #else .. #endif

Changes since RFC:
 - Moved CEC sub-device registration after CEC commands and events definitions patch
 - Removed get_notifier_get_byname
 - Added CEC_CORE select into i915 Kconfig
 - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn
 - Fixed CEC core return type on error
 - Moved to cros-ec-cec media platform directory
 - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname()
 - Fix Logical Address setup
 - Added comment about HW support
 - Removed memset of msg structures

Neil Armstrong (6):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Increase maximum mkbp event size
  mfd: cros-ec: Introduce CEC commands and events definitions.
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: platform: Add ChromeOS EC CEC driver

 drivers/gpu/drm/i915/Kconfig                     |   1 +
 drivers/gpu/drm/i915/intel_display.h             |  24 ++
 drivers/gpu/drm/i915/intel_drv.h                 |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c                |  13 +
 drivers/media/cec/cec-notifier.c                 |  11 +-
 drivers/media/platform/Kconfig                   |  11 +
 drivers/media/platform/Makefile                  |   2 +
 drivers/media/platform/cros-ec-cec/Makefile      |   1 +
 drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++++++++++++++++++++++
 drivers/mfd/cros_ec_dev.c                        |  16 ++
 drivers/platform/chrome/cros_ec_proto.c          |  40 ++-
 include/linux/mfd/cros_ec.h                      |   2 +-
 include/linux/mfd/cros_ec_commands.h             | 100 +++++++
 include/media/cec-notifier.h                     |  27 +-
 14 files changed, 581 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
 create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

-- 
2.7.4

[PATCH v7 1/6] media: cec-notifier: Get notifier by device and connector name

[Neil Armstrong]

In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.

This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.

But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/cec/cec-notifier.c | 11 ++++++++---
 include/media/cec-notifier.h     | 27 ++++++++++++++++++++++++---
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..dd2078b 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
 	struct list_head head;
 	struct kref kref;
 	struct device *dev;
+	const char *conn;
 	struct cec_adapter *cec_adap;
 	void (*callback)(struct cec_adapter *adap, u16 pa);
 
@@ -30,13 +31,14 @@ struct cec_notifier {
 static LIST_HEAD(cec_notifiers);
 static DEFINE_MUTEX(cec_notifiers_lock);
 
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char *conn)
 {
 	struct cec_notifier *n;
 
 	mutex_lock(&cec_notifiers_lock);
 	list_for_each_entry(n, &cec_notifiers, head) {
-		if (n->dev == dev) {
+		if (n->dev == dev &&
+		    (!conn || !strcmp(n->conn, conn))) {
 			kref_get(&n->kref);
 			mutex_unlock(&cec_notifiers_lock);
 			return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
 	if (!n)
 		goto unlock;
 	n->dev = dev;
+	if (conn)
+		n->conn = kstrdup(conn, GFP_KERNEL);
 	n->phys_addr = CEC_PHYS_ADDR_INVALID;
 	mutex_init(&n->lock);
 	kref_init(&n->kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
 	mutex_unlock(&cec_notifiers_lock);
 	return n;
 }
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
 
 static void cec_notifier_release(struct kref *kref)
 {
@@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
 		container_of(kref, struct cec_notifier, kref);
 
 	list_del(&n->head);
+	kfree(n->conn);
 	kfree(n);
 }
 
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..814eeef 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,8 +20,10 @@ struct cec_notifier;
 #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
 
 /**
- * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
  * @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
  *
  * If a notifier for device @dev already exists, then increase the refcount
  * and return that notifier.
@@ -31,7 +33,8 @@ struct cec_notifier;
  *
  * Return NULL if the memory could not be allocated.
  */
-struct cec_notifier *cec_notifier_get(struct device *dev);
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+					   const char *conn);
 
 /**
  * cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
 			       struct cec_notifier *notifier);
 
 #else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+							 const char *conn)
 {
 	/* A non-NULL pointer is expected on success */
 	return (struct cec_notifier *)0xdeadfeed;
@@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct cec_adapter *adap,
 #endif
 
 /**
+ * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * @dev: device that sends the events.
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+	return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
  * cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
  *
  * @n: the CEC notifier
-- 
2.7.4

[PATCH v7 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
 drivers/gpu/drm/i915/Kconfig         |  1 +
 drivers/gpu/drm/i915/intel_display.h | 24 ++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_drv.h     |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c    | 13 +++++++++++++
 4 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
 	select SYNC_FILE
 	select IOSF_MBI
 	select CRC32
+	select CEC_CORE if CEC_NOTIFIER
 	help
 	  Choose this option if you have a system that has "Intel Graphics
 	  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_display.h b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..70a365f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,30 @@ enum port {
 
 #define port_name(p) ((p) + 'A')
 
+/*
+ * Ports identifier referenced from other drivers.
+ * Expected to remain stable over time
+ */
+static inline const char *port_identifier(enum port port)
+{
+	switch (port) {
+	case PORT_A:
+		return "Port A";
+	case PORT_B:
+		return "Port B";
+	case PORT_C:
+		return "Port C";
+	case PORT_D:
+		return "Port D";
+	case PORT_E:
+		return "Port E";
+	case PORT_F:
+		return "Port F";
+	default:
+		return "<invalid>";
+	}
+}
+
 enum dpio_channel {
 	DPIO_CH0,
 	DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..a4e188d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include <drm/drm_dp_mst_helper.h>
 #include <drm/drm_rect.h>
 #include <drm/drm_atomic.h>
+#include <media/cec-notifier.h>
 
 /**
  * __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
 	bool has_audio;
 	bool rgb_quant_range_selectable;
 	struct intel_connector *attached_connector;
+	struct cec_notifier *cec_notifier;
 };
 
 struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..0bd7549 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
 		connected = true;
 	}
 
+	cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid);
+
 	return connected;
 }
 
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
 {
 	enum drm_connector_status status;
 	struct drm_i915_private *dev_priv = to_i915(connector->dev);
+	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 
 	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
 		      connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
 
 	intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
 
+	if (status != connector_status_connected)
+		cec_notifier_phys_addr_invalidate(intel_hdmi->cec_notifier);
+
 	return status;
 }
 
@@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder *encoder,
 
 static void intel_hdmi_destroy(struct drm_connector *connector)
 {
+	if (intel_attached_hdmi(connector)->cec_notifier)
+		cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
 	kfree(to_intel_connector(connector)->detect_edid);
 	drm_connector_cleanup(connector);
 	kfree(connector);
@@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
 		u32 temp = I915_READ(PEG_BAND_GAP_DATA);
 		I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
 	}
+
+	intel_hdmi->cec_notifier = cec_notifier_get_conn(dev->dev,
+							 port_identifier(port));
+	if (!intel_hdmi->cec_notifier)
+		DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

[PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Neil Armstrong]

Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.

Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
 include/linux/mfd/cros_ec.h             |  2 +-
 include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
 3 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..c4f6c44 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
 
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+			       struct cros_ec_command *msg,
+			       int version, uint32_t size)
+{
+	int ret;
+
+	msg->version = version;
+	msg->command = EC_CMD_GET_NEXT_EVENT;
+	msg->insize = size;
+	msg->outsize = 0;
+
+	ret = cros_ec_cmd_xfer(ec_dev, msg);
+	if (ret > 0) {
+		ec_dev->event_size = ret - 1;
+		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
+	}
+
+	return ret;
+}
+
 static int get_next_event(struct cros_ec_device *ec_dev)
 {
 	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
 	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
+	static int cmd_version = 1;
 	int ret;
 
 	if (ec_dev->suspended) {
@@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
 		return -EHOSTDOWN;
 	}
 
-	msg->version = 0;
-	msg->command = EC_CMD_GET_NEXT_EVENT;
-	msg->insize = sizeof(ec_dev->event_data);
-	msg->outsize = 0;
+	if (cmd_version == 1) {
+		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+				sizeof(struct ec_response_get_next_event_v1));
+		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
+			return ret;
 
-	ret = cros_ec_cmd_xfer(ec_dev, msg);
-	if (ret > 0) {
-		ec_dev->event_size = ret - 1;
-		memcpy(&ec_dev->event_data, msg->data,
-		       sizeof(ec_dev->event_data));
+		/* Fallback to version 0 for future send attempts */
+		cmd_version = 0;
 	}
 
+	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+				  sizeof(struct ec_response_get_next_event));
+
 	return ret;
 }
 
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f36125e..32caef3 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
 	bool mkbp_event_supported;
 	struct blocking_notifier_head event_notifier;
 
-	struct ec_response_get_next_event event_data;
+	struct ec_response_get_next_event_v1 event_data;
 	int event_size;
 	u32 host_event_wake_mask;
 };
diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
index f2edd99..cc0768e 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
 	uint32_t   sysrq;
 } __packed;
 
+union ec_response_get_next_data_v1 {
+	uint8_t   key_matrix[16];
+
+	/* Unaligned */
+	uint32_t  host_event;
+
+	uint32_t   buttons;
+	uint32_t   switches;
+	uint32_t   sysrq;
+	uint32_t   cec_events;
+	uint8_t    cec_message[16];
+} __packed;
+
 struct ec_response_get_next_event {
 	uint8_t event_type;
 	/* Followed by event data if any */
 	union ec_response_get_next_data data;
 } __packed;
 
+struct ec_response_get_next_event_v1 {
+	uint8_t event_type;
+	/* Followed by event data if any */
+	union ec_response_get_next_data_v1 data;
+} __packed;
+
 /* Bit indices for buttons and switches.*/
 /* Buttons */
 #define EC_MKBP_POWER_BUTTON	0
-- 
2.7.4

Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Hans Verkuil]

On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
> 
> Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Regards,

	Hans

> ---
>  drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
>  include/linux/mfd/cros_ec.h             |  2 +-
>  include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
>  3 files changed, 51 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>  
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +			       struct cros_ec_command *msg,
> +			       int version, uint32_t size)
> +{
> +	int ret;
> +
> +	msg->version = version;
> +	msg->command = EC_CMD_GET_NEXT_EVENT;
> +	msg->insize = size;
> +	msg->outsize = 0;
> +
> +	ret = cros_ec_cmd_xfer(ec_dev, msg);
> +	if (ret > 0) {
> +		ec_dev->event_size = ret - 1;
> +		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> +	}
> +
> +	return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>  	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>  	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> +	static int cmd_version = 1;
>  	int ret;
>  
>  	if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>  		return -EHOSTDOWN;
>  	}
>  
> -	msg->version = 0;
> -	msg->command = EC_CMD_GET_NEXT_EVENT;
> -	msg->insize = sizeof(ec_dev->event_data);
> -	msg->outsize = 0;
> +	if (cmd_version == 1) {
> +		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +				sizeof(struct ec_response_get_next_event_v1));
> +		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> +			return ret;
>  
> -	ret = cros_ec_cmd_xfer(ec_dev, msg);
> -	if (ret > 0) {
> -		ec_dev->event_size = ret - 1;
> -		memcpy(&ec_dev->event_data, msg->data,
> -		       sizeof(ec_dev->event_data));
> +		/* Fallback to version 0 for future send attempts */
> +		cmd_version = 0;
>  	}
>  
> +	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +				  sizeof(struct ec_response_get_next_event));
> +
>  	return ret;
>  }
>  
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
>  	bool mkbp_event_supported;
>  	struct blocking_notifier_head event_notifier;
>  
> -	struct ec_response_get_next_event event_data;
> +	struct ec_response_get_next_event_v1 event_data;
>  	int event_size;
>  	u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..cc0768e 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
>  	uint32_t   sysrq;
>  } __packed;
>  
> +union ec_response_get_next_data_v1 {
> +	uint8_t   key_matrix[16];
> +
> +	/* Unaligned */
> +	uint32_t  host_event;
> +
> +	uint32_t   buttons;
> +	uint32_t   switches;
> +	uint32_t   sysrq;
> +	uint32_t   cec_events;
> +	uint8_t    cec_message[16];
> +} __packed;
> +
>  struct ec_response_get_next_event {
>  	uint8_t event_type;
>  	/* Followed by event data if any */
>  	union ec_response_get_next_data data;
>  } __packed;
>  
> +struct ec_response_get_next_event_v1 {
> +	uint8_t event_type;
> +	/* Followed by event data if any */
> +	union ec_response_get_next_data_v1 data;
> +} __packed;
> +
>  /* Bit indices for buttons and switches.*/
>  /* Buttons */
>  #define EC_MKBP_POWER_BUTTON	0
> 

Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Lee Jones]

On Fri, 01 Jun 2018, Neil Armstrong wrote:

> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
> 
> Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
>  include/linux/mfd/cros_ec.h             |  2 +-
>  include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
>  3 files changed, 51 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>  
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +			       struct cros_ec_command *msg,
> +			       int version, uint32_t size)
> +{
> +	int ret;
> +
> +	msg->version = version;
> +	msg->command = EC_CMD_GET_NEXT_EVENT;
> +	msg->insize = size;
> +	msg->outsize = 0;
> +
> +	ret = cros_ec_cmd_xfer(ec_dev, msg);
> +	if (ret > 0) {
> +		ec_dev->event_size = ret - 1;
> +		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> +	}
> +
> +	return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>  	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>  	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> +	static int cmd_version = 1;
>  	int ret;
>  
>  	if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>  		return -EHOSTDOWN;
>  	}
>  
> -	msg->version = 0;
> -	msg->command = EC_CMD_GET_NEXT_EVENT;
> -	msg->insize = sizeof(ec_dev->event_data);
> -	msg->outsize = 0;
> +	if (cmd_version == 1) {
> +		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +				sizeof(struct ec_response_get_next_event_v1));
> +		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> +			return ret;
>  
> -	ret = cros_ec_cmd_xfer(ec_dev, msg);
> -	if (ret > 0) {
> -		ec_dev->event_size = ret - 1;
> -		memcpy(&ec_dev->event_data, msg->data,
> -		       sizeof(ec_dev->event_data));
> +		/* Fallback to version 0 for future send attempts */
> +		cmd_version = 0;
>  	}
>  
> +	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +				  sizeof(struct ec_response_get_next_event));
> +
>  	return ret;
>  }
>  
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
>  	bool mkbp_event_supported;
>  	struct blocking_notifier_head event_notifier;
>  
> -	struct ec_response_get_next_event event_data;
> +	struct ec_response_get_next_event_v1 event_data;
>  	int event_size;
>  	u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..cc0768e 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
>  	uint32_t   sysrq;
>  } __packed;
>  
> +union ec_response_get_next_data_v1 {
> +	uint8_t   key_matrix[16];
> +
> +	/* Unaligned */

That's funny!

> +	uint32_t  host_event;
> +
> +	uint32_t   buttons;
> +	uint32_t   switches;
> +	uint32_t   sysrq;
> +	uint32_t   cec_events;
> +	uint8_t    cec_message[16];

Since there are some whitespace alignment issues in here.

> +} __packed;

How come these guys have kerneldoc headers?

>  struct ec_response_get_next_event {
>  	uint8_t event_type;
>  	/* Followed by event data if any */
>  	union ec_response_get_next_data data;
>  } __packed;
>  
> +struct ec_response_get_next_event_v1 {
> +	uint8_t event_type;
> +	/* Followed by event data if any */
> +	union ec_response_get_next_data_v1 data;
> +} __packed;
> +
>  /* Bit indices for buttons and switches.*/
>  /* Buttons */
>  #define EC_MKBP_POWER_BUTTON	0

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Neil Armstrong]

Hi Lee,

On 18/06/2018 09:44, Lee Jones wrote:
> On Fri, 01 Jun 2018, Neil Armstrong wrote:
> 
>> Having a 16 byte mkbp event size makes it possible to send CEC
>> messages from the EC to the AP directly inside the mkbp event
>> instead of first doing a notification and then a read.
>>
>> Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>>  drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
>>  include/linux/mfd/cros_ec.h             |  2 +-
>>  include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
>>  3 files changed, 51 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
>> index e7bbdf9..c4f6c44 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>>  }
>>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>>  
>> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
>> +			       struct cros_ec_command *msg,
>> +			       int version, uint32_t size)
>> +{
>> +	int ret;
>> +
>> +	msg->version = version;
>> +	msg->command = EC_CMD_GET_NEXT_EVENT;
>> +	msg->insize = size;
>> +	msg->outsize = 0;
>> +
>> +	ret = cros_ec_cmd_xfer(ec_dev, msg);
>> +	if (ret > 0) {
>> +		ec_dev->event_size = ret - 1;
>> +		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>>  static int get_next_event(struct cros_ec_device *ec_dev)
>>  {
>>  	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>>  	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
>> +	static int cmd_version = 1;
>>  	int ret;
>>  
>>  	if (ec_dev->suspended) {
>> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>>  		return -EHOSTDOWN;
>>  	}
>>  
>> -	msg->version = 0;
>> -	msg->command = EC_CMD_GET_NEXT_EVENT;
>> -	msg->insize = sizeof(ec_dev->event_data);
>> -	msg->outsize = 0;
>> +	if (cmd_version == 1) {
>> +		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> +				sizeof(struct ec_response_get_next_event_v1));
>> +		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
>> +			return ret;
>>  
>> -	ret = cros_ec_cmd_xfer(ec_dev, msg);
>> -	if (ret > 0) {
>> -		ec_dev->event_size = ret - 1;
>> -		memcpy(&ec_dev->event_data, msg->data,
>> -		       sizeof(ec_dev->event_data));
>> +		/* Fallback to version 0 for future send attempts */
>> +		cmd_version = 0;
>>  	}
>>  
>> +	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> +				  sizeof(struct ec_response_get_next_event));
>> +
>>  	return ret;
>>  }
>>  
>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index f36125e..32caef3 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -147,7 +147,7 @@ struct cros_ec_device {
>>  	bool mkbp_event_supported;
>>  	struct blocking_notifier_head event_notifier;
>>  
>> -	struct ec_response_get_next_event event_data;
>> +	struct ec_response_get_next_event_v1 event_data;
>>  	int event_size;
>>  	u32 host_event_wake_mask;
>>  };
>> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
>> index f2edd99..cc0768e 100644
>> --- a/include/linux/mfd/cros_ec_commands.h
>> +++ b/include/linux/mfd/cros_ec_commands.h
>> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
>>  	uint32_t   sysrq;
>>  } __packed;
>>  
>> +union ec_response_get_next_data_v1 {
>> +	uint8_t   key_matrix[16];
>> +
>> +	/* Unaligned */
> 
> That's funny!
> 
>> +	uint32_t  host_event;
>> +
>> +	uint32_t   buttons;
>> +	uint32_t   switches;
>> +	uint32_t   sysrq;
>> +	uint32_t   cec_events;
>> +	uint8_t    cec_message[16];
> 
> Since there are some whitespace alignment issues in here.
> 
>> +} __packed;
> 
> How come these guys have kerneldoc headers?

Can you explicit what should be changed here ?

Thanks,
Neil

> 
>>  struct ec_response_get_next_event {
>>  	uint8_t event_type;
>>  	/* Followed by event data if any */
>>  	union ec_response_get_next_data data;
>>  } __packed;
>>  
>> +struct ec_response_get_next_event_v1 {
>> +	uint8_t event_type;
>> +	/* Followed by event data if any */
>> +	union ec_response_get_next_data_v1 data;
>> +} __packed;
>> +
>>  /* Bit indices for buttons and switches.*/
>>  /* Buttons */
>>  #define EC_MKBP_POWER_BUTTON	0
> 

Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Lee Jones]

On Mon, 18 Jun 2018, Neil Armstrong wrote:

> Hi Lee,
> 
> On 18/06/2018 09:44, Lee Jones wrote:
> > On Fri, 01 Jun 2018, Neil Armstrong wrote:
> > 
> >> Having a 16 byte mkbp event size makes it possible to send CEC
> >> messages from the EC to the AP directly inside the mkbp event
> >> instead of first doing a notification and then a read.
> >>
> >> Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> ---
> >>  drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
> >>  include/linux/mfd/cros_ec.h             |  2 +-
> >>  include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
> >>  3 files changed, 51 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> >> index e7bbdf9..c4f6c44 100644
> >> --- a/drivers/platform/chrome/cros_ec_proto.c
> >> +++ b/drivers/platform/chrome/cros_ec_proto.c
> >> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> >>  }
> >>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
> >>  
> >> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> >> +			       struct cros_ec_command *msg,
> >> +			       int version, uint32_t size)
> >> +{
> >> +	int ret;
> >> +
> >> +	msg->version = version;
> >> +	msg->command = EC_CMD_GET_NEXT_EVENT;
> >> +	msg->insize = size;
> >> +	msg->outsize = 0;
> >> +
> >> +	ret = cros_ec_cmd_xfer(ec_dev, msg);
> >> +	if (ret > 0) {
> >> +		ec_dev->event_size = ret - 1;
> >> +		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> >> +	}
> >> +
> >> +	return ret;
> >> +}
> >> +
> >>  static int get_next_event(struct cros_ec_device *ec_dev)
> >>  {
> >>  	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> >>  	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> >> +	static int cmd_version = 1;
> >>  	int ret;
> >>  
> >>  	if (ec_dev->suspended) {
> >> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> >>  		return -EHOSTDOWN;
> >>  	}
> >>  
> >> -	msg->version = 0;
> >> -	msg->command = EC_CMD_GET_NEXT_EVENT;
> >> -	msg->insize = sizeof(ec_dev->event_data);
> >> -	msg->outsize = 0;
> >> +	if (cmd_version == 1) {
> >> +		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> >> +				sizeof(struct ec_response_get_next_event_v1));
> >> +		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> >> +			return ret;
> >>  
> >> -	ret = cros_ec_cmd_xfer(ec_dev, msg);
> >> -	if (ret > 0) {
> >> -		ec_dev->event_size = ret - 1;
> >> -		memcpy(&ec_dev->event_data, msg->data,
> >> -		       sizeof(ec_dev->event_data));
> >> +		/* Fallback to version 0 for future send attempts */
> >> +		cmd_version = 0;
> >>  	}
> >>  
> >> +	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> >> +				  sizeof(struct ec_response_get_next_event));
> >> +
> >>  	return ret;
> >>  }
> >>  
> >> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> >> index f36125e..32caef3 100644
> >> --- a/include/linux/mfd/cros_ec.h
> >> +++ b/include/linux/mfd/cros_ec.h
> >> @@ -147,7 +147,7 @@ struct cros_ec_device {
> >>  	bool mkbp_event_supported;
> >>  	struct blocking_notifier_head event_notifier;
> >>  
> >> -	struct ec_response_get_next_event event_data;
> >> +	struct ec_response_get_next_event_v1 event_data;
> >>  	int event_size;
> >>  	u32 host_event_wake_mask;
> >>  };
> >> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> >> index f2edd99..cc0768e 100644
> >> --- a/include/linux/mfd/cros_ec_commands.h
> >> +++ b/include/linux/mfd/cros_ec_commands.h
> >> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
> >>  	uint32_t   sysrq;
> >>  } __packed;
> >>  
> >> +union ec_response_get_next_data_v1 {
> >> +	uint8_t   key_matrix[16];
> >> +
> >> +	/* Unaligned */
> > 
> > That's funny!
> > 
> >> +	uint32_t  host_event;
> >> +
> >> +	uint32_t   buttons;
> >> +	uint32_t   switches;
> >> +	uint32_t   sysrq;
> >> +	uint32_t   cec_events;
> >> +	uint8_t    cec_message[16];
> > 
> > Since there are some whitespace alignment issues in here.

Fix the white space issues.

> >> +} __packed;
> > 
> > How come these guys have kerneldoc headers?

Consider using kerneldoc headers (not required for this patch).

> Can you explicit what should be changed here ?

-^

> >>  struct ec_response_get_next_event {
> >>  	uint8_t event_type;
> >>  	/* Followed by event data if any */
> >>  	union ec_response_get_next_data data;
> >>  } __packed;
> >>  
> >> +struct ec_response_get_next_event_v1 {
> >> +	uint8_t event_type;
> >> +	/* Followed by event data if any */
> >> +	union ec_response_get_next_data_v1 data;
> >> +} __packed;
> >> +
> >>  /* Bit indices for buttons and switches.*/
> >>  /* Buttons */
> >>  #define EC_MKBP_POWER_BUTTON	0
> > 
> 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

[Neil Armstrong]

Hi Lee,

On 03/07/2018 11:43, Lee Jones wrote:
> On Mon, 18 Jun 2018, Neil Armstrong wrote:
> 
>> Hi Lee,
>>
>> On 18/06/2018 09:44, Lee Jones wrote:
>>> On Fri, 01 Jun 2018, Neil Armstrong wrote:
>>>
>>>> Having a 16 byte mkbp event size makes it possible to send CEC
>>>> messages from the EC to the AP directly inside the mkbp event
>>>> instead of first doing a notification and then a read.
>>>>
>>>> Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>> ---
>>>>  drivers/platform/chrome/cros_ec_proto.c | 40 +++++++++++++++++++++++++--------
>>>>  include/linux/mfd/cros_ec.h             |  2 +-
>>>>  include/linux/mfd/cros_ec_commands.h    | 19 ++++++++++++++++
>>>>  3 files changed, 51 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
>>>> index e7bbdf9..c4f6c44 100644
>>>> --- a/drivers/platform/chrome/cros_ec_proto.c
>>>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>>>> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
>>>>  }
>>>>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>>>>  
>>>> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
>>>> +			       struct cros_ec_command *msg,
>>>> +			       int version, uint32_t size)
>>>> +{
>>>> +	int ret;
>>>> +
>>>> +	msg->version = version;
>>>> +	msg->command = EC_CMD_GET_NEXT_EVENT;
>>>> +	msg->insize = size;
>>>> +	msg->outsize = 0;
>>>> +
>>>> +	ret = cros_ec_cmd_xfer(ec_dev, msg);
>>>> +	if (ret > 0) {
>>>> +		ec_dev->event_size = ret - 1;
>>>> +		memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
>>>> +	}
>>>> +
>>>> +	return ret;
>>>> +}
>>>> +
>>>>  static int get_next_event(struct cros_ec_device *ec_dev)
>>>>  {
>>>>  	u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>>>>  	struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
>>>> +	static int cmd_version = 1;
>>>>  	int ret;
>>>>  
>>>>  	if (ec_dev->suspended) {
>>>> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>>>>  		return -EHOSTDOWN;
>>>>  	}
>>>>  
>>>> -	msg->version = 0;
>>>> -	msg->command = EC_CMD_GET_NEXT_EVENT;
>>>> -	msg->insize = sizeof(ec_dev->event_data);
>>>> -	msg->outsize = 0;
>>>> +	if (cmd_version == 1) {
>>>> +		ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>>>> +				sizeof(struct ec_response_get_next_event_v1));
>>>> +		if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
>>>> +			return ret;
>>>>  
>>>> -	ret = cros_ec_cmd_xfer(ec_dev, msg);
>>>> -	if (ret > 0) {
>>>> -		ec_dev->event_size = ret - 1;
>>>> -		memcpy(&ec_dev->event_data, msg->data,
>>>> -		       sizeof(ec_dev->event_data));
>>>> +		/* Fallback to version 0 for future send attempts */
>>>> +		cmd_version = 0;
>>>>  	}
>>>>  
>>>> +	ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>>>> +				  sizeof(struct ec_response_get_next_event));
>>>> +
>>>>  	return ret;
>>>>  }
>>>>  
>>>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>>>> index f36125e..32caef3 100644
>>>> --- a/include/linux/mfd/cros_ec.h
>>>> +++ b/include/linux/mfd/cros_ec.h
>>>> @@ -147,7 +147,7 @@ struct cros_ec_device {
>>>>  	bool mkbp_event_supported;
>>>>  	struct blocking_notifier_head event_notifier;
>>>>  
>>>> -	struct ec_response_get_next_event event_data;
>>>> +	struct ec_response_get_next_event_v1 event_data;
>>>>  	int event_size;
>>>>  	u32 host_event_wake_mask;
>>>>  };
>>>> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
>>>> index f2edd99..cc0768e 100644
>>>> --- a/include/linux/mfd/cros_ec_commands.h
>>>> +++ b/include/linux/mfd/cros_ec_commands.h
>>>> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
>>>>  	uint32_t   sysrq;
>>>>  } __packed;
>>>>  
>>>> +union ec_response_get_next_data_v1 {
>>>> +	uint8_t   key_matrix[16];
>>>> +
>>>> +	/* Unaligned */
>>>
>>> That's funny!
>>>
>>>> +	uint32_t  host_event;
>>>> +
>>>> +	uint32_t   buttons;
>>>> +	uint32_t   switches;
>>>> +	uint32_t   sysrq;
>>>> +	uint32_t   cec_events;
>>>> +	uint8_t    cec_message[16];
>>>
>>> Since there are some whitespace alignment issues in here.
> 
> Fix the white space issues.

Ok

> 
>>>> +} __packed;
>>>
>>> How come these guys have kerneldoc headers?
> 
> Consider using kerneldoc headers (not required for this patch).

I already used kerneldoc for the other patch as requested by Enric.

> 
>> Can you explicit what should be changed here ?
> 
> -^

Ok

Thanks,
Neil

> 
>>>>  struct ec_response_get_next_event {
>>>>  	uint8_t event_type;
>>>>  	/* Followed by event data if any */
>>>>  	union ec_response_get_next_data data;
>>>>  } __packed;
>>>>  
>>>> +struct ec_response_get_next_event_v1 {
>>>> +	uint8_t event_type;
>>>> +	/* Followed by event data if any */
>>>> +	union ec_response_get_next_data_v1 data;
>>>> +} __packed;
>>>> +
>>>>  /* Bit indices for buttons and switches.*/
>>>>  /* Buttons */
>>>>  #define EC_MKBP_POWER_BUTTON	0
>>>
>>
> 

[PATCH v7 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.

[Neil Armstrong]

The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 include/linux/mfd/cros_ec_commands.h | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
index cc0768e..fe33a81 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
 	EC_FEATURE_MOTION_SENSE_FIFO = 24,
 	/* EC has RTC feature that can be controlled by host commands */
 	EC_FEATURE_RTC = 27,
+	/* EC supports CEC commands */
+	EC_FEATURE_CEC = 35,
 };
 
 #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
 	/* EC sent a sysrq command */
 	EC_MKBP_EVENT_SYSRQ = 6,
 
+	/* Notify the AP that something happened on CEC */
+	EC_MKBP_EVENT_CEC_EVENT = 8,
+
+	/* Send an incoming CEC message to the AP */
+	EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
 	/* Number of MKBP events */
 	EC_MKBP_EVENT_COUNT,
 };
@@ -2850,6 +2858,79 @@ struct ec_params_reboot_ec {
 
 /*****************************************************************************/
 /*
+ * HDMI CEC commands
+ *
+ * These commands are for sending and receiving message via HDMI CEC
+ */
+#define EC_MAX_CEC_MSG_LEN 16
+
+/* CEC message from the AP to be written on the CEC bus */
+#define EC_CMD_CEC_WRITE_MSG 0x00B8
+
+/**
+ * struct ec_params_cec_write - Message to write to the CEC bus
+ * @msg: message content to write to the CEC bus
+ */
+struct ec_params_cec_write {
+	uint8_t msg[EC_MAX_CEC_MSG_LEN];
+} __packed;
+
+/* Set various CEC parameters */
+#define EC_CMD_CEC_SET 0x00BA
+
+/**
+ * struct ec_params_cec_set - CEC parameters set
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ * @val: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
+ *	or 1 to enable CEC functionality, in case cmd is CEC_CMD_LOGICAL_ADDRESS,
+ *	this field encodes the requested logical address between 0 and 15
+ *	or 0xff to unregister
+ */
+struct ec_params_cec_set {
+	uint8_t cmd; /* enum cec_command */
+	uint8_t val;
+} __packed;
+
+/* Read various CEC parameters */
+#define EC_CMD_CEC_GET 0x00BB
+
+/**
+ * struct ec_params_cec_get - CEC parameters get
+ * @cmd: parameter type, can be CEC_CMD_ENABLE or CEC_CMD_LOGICAL_ADDRESS
+ */
+struct ec_params_cec_get {
+	uint8_t cmd; /* enum cec_command */
+} __packed;
+
+/**
+ * struct ec_response_cec_get - CEC parameters get response
+ * @val: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
+ *	disabled or 1 if CEC functionality is enabled,
+ *	in case cmd was CEC_CMD_LOGICAL_ADDRESS, this will encode the
+ *	configured logical address between 0 and 15 or 0xff if unregistered
+ */
+struct ec_response_cec_get {
+	uint8_t val;
+} __packed;
+
+/* CEC parameters command */
+enum ec_cec_command {
+	/* CEC reading, writing and events enable */
+	CEC_CMD_ENABLE,
+	/* CEC logical address  */
+	CEC_CMD_LOGICAL_ADDRESS,
+};
+
+/* Events from CEC to AP */
+enum mkbp_cec_event {
+	/* Outgoing message was acknowledged by a follower */
+	EC_MKBP_CEC_SEND_OK			= BIT(0),
+	/* Outgoing message was not acknowledged */
+	EC_MKBP_CEC_SEND_FAILED			= BIT(1),
+};
+
+/*****************************************************************************/
+/*
  * Special commands
  *
  * These do not follow the normal rules for commands.  See each command for
-- 
2.7.4

Re: [PATCH v7 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.

[Lee Jones]

On Fri, 01 Jun 2018, Neil Armstrong wrote:

> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
>  include/linux/mfd/cros_ec_commands.h | 81 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 81 insertions(+)

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

[Neil Armstrong]

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/mfd/cros_ec_dev.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 1d6dc5c..272969e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev *ec)
 	kfree(msg);
 }
 
+static const struct mfd_cell cros_ec_cec_cells[] = {
+	{ .name = "cros-ec-cec" }
+};
+
 static const struct mfd_cell cros_ec_rtc_cells[] = {
 	{ .name = "cros-ec-rtc" }
 };
@@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
 	if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
 		cros_ec_sensors_register(ec);
 
+	/* Check whether this EC instance has CEC host command support */
+	if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
+		retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
+					 cros_ec_cec_cells,
+					 ARRAY_SIZE(cros_ec_cec_cells),
+					 NULL, 0, NULL);
+		if (retval)
+			dev_err(ec->dev,
+				"failed to add cros-ec-cec device: %d\n",
+				retval);
+	}
+
 	/* Check whether this EC instance has RTC host command support */
 	if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
 		retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
-- 
2.7.4

Re: [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

[Lee Jones]

On Fri, 01 Jun 2018, Neil Armstrong wrote:

> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
>  drivers/mfd/cros_ec_dev.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

[Neil Armstrong]

Hi Lee,

On 04/07/2018 09:47, Lee Jones wrote:
> On Fri, 01 Jun 2018, Neil Armstrong wrote:
> 
>> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
>> when the CEC feature bit is present.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
>> ---
>>  drivers/mfd/cros_ec_dev.c | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
> 
> For my own reference:
>   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> 

Should I keep these Acked-for-MFD-by for the v8 ?

Neil

Re: [PATCH v7 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

[Lee Jones]

On Wed, 04 Jul 2018, Neil Armstrong wrote:

> Hi Lee,
> 
> On 04/07/2018 09:47, Lee Jones wrote:
> > On Fri, 01 Jun 2018, Neil Armstrong wrote:
> > 
> >> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> >> when the CEC feature bit is present.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> >> ---
> >>  drivers/mfd/cros_ec_dev.c | 16 ++++++++++++++++
> >>  1 file changed, 16 insertions(+)
> > 
> > For my own reference:
> >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > 
> 
> Should I keep these Acked-for-MFD-by for the v8 ?

Yes please.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v7 6/6] media: platform: Add ChromeOS EC CEC driver

[Neil Armstrong]

The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.

This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.

The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.

The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 drivers/media/platform/Kconfig                   |  11 +
 drivers/media/platform/Makefile                  |   2 +
 drivers/media/platform/cros-ec-cec/Makefile      |   1 +
 drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++++++++++++++++++++++
 4 files changed, 361 insertions(+)
 create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
 create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..bc37ecf 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_CROS_EC_CEC
+	tristate "ChromeOS EC CEC driver"
+	depends on MFD_CROS_EC || COMPILE_TEST
+	select CEC_CORE
+	select CEC_NOTIFIER
+	---help---
+	  If you say yes here you will get support for the
+	  ChromeOS Embedded Controller's CEC.
+	  The CEC bus is present in the HDMI connector and enables communication
+	  between compatible devices.
+
 config VIDEO_MESON_AO_CEC
 	tristate "Amlogic Meson AO CEC driver"
 	depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)		+= qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS)		+= qcom/venus/
 
 obj-y					+= meson/
+
+obj-y					+= cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 0000000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 0000000..7bc4d8a
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for ChromeOS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/dmi.h>
+#include <linux/pci.h>
+#include <linux/cec.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <media/cec.h>
+#include <media/cec-notifier.h>
+#include <linux/mfd/cros_ec.h>
+#include <linux/mfd/cros_ec_commands.h>
+
+#define DRV_NAME	"cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+	struct cros_ec_device *cros_ec;
+	struct notifier_block notifier;
+	struct cec_adapter *adap;
+	struct cec_notifier *notify;
+	struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+	struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+	uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+	unsigned int len = cros_ec->event_size;
+
+	cros_ec_cec->rx_msg.len = len;
+	memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+	cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+	struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+	uint32_t events = cros_ec->event_data.data.cec_events;
+
+	if (events & EC_MKBP_CEC_SEND_OK)
+		cec_transmit_attempt_done(cros_ec_cec->adap,
+					  CEC_TX_STATUS_OK);
+
+	/* FW takes care of all retries, tell core to avoid more retries */
+	if (events & EC_MKBP_CEC_SEND_FAILED)
+		cec_transmit_attempt_done(cros_ec_cec->adap,
+					  CEC_TX_STATUS_MAX_RETRIES |
+					  CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+			     unsigned long queued_during_suspend,
+			     void *_notify)
+{
+	struct cros_ec_cec *cros_ec_cec;
+	struct cros_ec_device *cros_ec;
+
+	cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+	cros_ec = cros_ec_cec->cros_ec;
+
+	if (cros_ec->event_data.event_type == EC_MKBP_EVENT_CEC_EVENT) {
+		handle_cec_event(cros_ec_cec);
+		return NOTIFY_OK;
+	}
+
+	if (cros_ec->event_data.event_type == EC_MKBP_EVENT_CEC_MESSAGE) {
+		handle_cec_message(cros_ec_cec);
+		return NOTIFY_OK;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static int cros_ec_cec_set_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+	struct cros_ec_cec *cros_ec_cec = adap->priv;
+	struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+	struct {
+		struct cros_ec_command msg;
+		struct ec_params_cec_set data;
+	} __packed msg = {};
+	int ret;
+
+	msg.msg.command = EC_CMD_CEC_SET;
+	msg.msg.outsize = sizeof(msg.data);
+	msg.data.cmd = CEC_CMD_LOGICAL_ADDRESS;
+	msg.data.val = logical_addr;
+
+	ret = cros_ec_cmd_xfer_status(cros_ec, &msg.msg);
+	if (ret < 0) {
+		dev_err(cros_ec->dev,
+			"error setting CEC logical address on EC: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int cros_ec_cec_transmit(struct cec_adapter *adap, u8 attempts,
+				u32 signal_free_time, struct cec_msg *cec_msg)
+{
+	struct cros_ec_cec *cros_ec_cec = adap->priv;
+	struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+	struct {
+		struct cros_ec_command msg;
+		struct ec_params_cec_write data;
+	} __packed msg = {};
+	int ret;
+
+	msg.msg.command = EC_CMD_CEC_WRITE_MSG;
+	msg.msg.outsize = cec_msg->len;
+	memcpy(msg.data.msg, cec_msg->msg, cec_msg->len);
+
+	ret = cros_ec_cmd_xfer_status(cros_ec, &msg.msg);
+	if (ret < 0) {
+		dev_err(cros_ec->dev,
+			"error writing CEC msg on EC: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int cros_ec_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+	struct cros_ec_cec *cros_ec_cec = adap->priv;
+	struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+	struct {
+		struct cros_ec_command msg;
+		struct ec_params_cec_set data;
+	} __packed msg = {};
+	int ret;
+
+	msg.msg.command = EC_CMD_CEC_SET;
+	msg.msg.outsize = sizeof(msg.data);
+	msg.data.cmd = CEC_CMD_ENABLE;
+	msg.data.val = enable;
+
+	ret = cros_ec_cmd_xfer_status(cros_ec, &msg.msg);
+	if (ret < 0) {
+		dev_err(cros_ec->dev,
+			"error %sabling CEC on EC: %d\n",
+			(enable ? "en" : "dis"), ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct cec_adap_ops cros_ec_cec_ops = {
+	.adap_enable = cros_ec_cec_adap_enable,
+	.adap_log_addr = cros_ec_cec_set_log_addr,
+	.adap_transmit = cros_ec_cec_transmit,
+};
+
+#ifdef CONFIG_PM_SLEEP
+static int cros_ec_cec_suspend(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct cros_ec_cec *cros_ec_cec = dev_get_drvdata(&pdev->dev);
+
+	if (device_may_wakeup(dev))
+		enable_irq_wake(cros_ec_cec->cros_ec->irq);
+
+	return 0;
+}
+
+static int cros_ec_cec_resume(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct cros_ec_cec *cros_ec_cec = dev_get_drvdata(&pdev->dev);
+
+	if (device_may_wakeup(dev))
+		disable_irq_wake(cros_ec_cec->cros_ec->irq);
+
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(cros_ec_cec_pm_ops,
+	cros_ec_cec_suspend, cros_ec_cec_resume);
+
+#if IS_ENABLED(CONFIG_PCI) && IS_ENABLED(CONFIG_DMI)
+
+/*
+ * The Firmware only handles a single CEC interface tied to a single HDMI
+ * connector we specify along with the DRM device name handling the HDMI output
+ */
+
+struct cec_dmi_match {
+	char *sys_vendor;
+	char *product_name;
+	char *devname;
+	char *conn;
+};
+
+static const struct cec_dmi_match cec_dmi_match_table[] = {
+	/* Google Fizz */
+	{ "Google", "Fizz", "0000:00:02.0", "Port B" },
+};
+
+static int cros_ec_cec_get_notifier(struct device *dev,
+				    struct cec_notifier **notify)
+{
+	int i;
+
+	for (i = 0 ; i < ARRAY_SIZE(cec_dmi_match_table) ; ++i) {
+		const struct cec_dmi_match *m = &cec_dmi_match_table[i];
+
+		if (dmi_match(DMI_SYS_VENDOR, m->sys_vendor) &&
+		    dmi_match(DMI_PRODUCT_NAME, m->product_name)) {
+			struct device *d;
+
+			/* Find the device, bail out if not yet registered */
+			d = bus_find_device_by_name(&pci_bus_type, NULL,
+						    m->devname);
+			if (!d)
+				return -EPROBE_DEFER;
+
+			*notify = cec_notifier_get_conn(d, m->conn);
+			return 0;
+		}
+	}
+
+	/* Hardware support must be added in the cec_dmi_match_table */
+	dev_warn(dev, "CEC notifier not configured for this hardware\n");
+
+	return -ENODEV;
+}
+
+#else
+
+static int cros_ec_cec_get_notifier(struct device *dev,
+				    struct cec_notifier **notify)
+{
+	return -ENODEV;
+}
+
+#endif
+
+static int cros_ec_cec_probe(struct platform_device *pdev)
+{
+	struct cros_ec_dev *ec_dev = dev_get_drvdata(pdev->dev.parent);
+	struct cros_ec_device *cros_ec = ec_dev->ec_dev;
+	struct cros_ec_cec *cros_ec_cec;
+	int ret;
+
+	cros_ec_cec = devm_kzalloc(&pdev->dev, sizeof(*cros_ec_cec),
+				   GFP_KERNEL);
+	if (!cros_ec_cec)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, cros_ec_cec);
+	cros_ec_cec->cros_ec = cros_ec;
+
+	ret = cros_ec_cec_get_notifier(&pdev->dev, &cros_ec_cec->notify);
+	if (ret)
+		return ret;
+
+	ret = device_init_wakeup(&pdev->dev, 1);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to initialize wakeup\n");
+		return ret;
+	}
+
+	cros_ec_cec->adap = cec_allocate_adapter(&cros_ec_cec_ops, cros_ec_cec,
+						 DRV_NAME, CEC_CAP_DEFAULTS, 1);
+	if (IS_ERR(cros_ec_cec->adap))
+		return PTR_ERR(cros_ec_cec->adap);
+
+	/* Get CEC events from the EC. */
+	cros_ec_cec->notifier.notifier_call = cros_ec_cec_event;
+	ret = blocking_notifier_chain_register(&cros_ec->event_notifier,
+					       &cros_ec_cec->notifier);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to register notifier\n");
+		cec_delete_adapter(cros_ec_cec->adap);
+		return ret;
+	}
+
+	ret = cec_register_adapter(cros_ec_cec->adap, &pdev->dev);
+	if (ret < 0) {
+		cec_delete_adapter(cros_ec_cec->adap);
+		return ret;
+	}
+
+	cec_register_cec_notifier(cros_ec_cec->adap, cros_ec_cec->notify);
+
+	return 0;
+}
+
+static int cros_ec_cec_remove(struct platform_device *pdev)
+{
+	struct cros_ec_cec *cros_ec_cec = platform_get_drvdata(pdev);
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	ret = blocking_notifier_chain_unregister(
+			&cros_ec_cec->cros_ec->event_notifier,
+			&cros_ec_cec->notifier);
+
+	if (ret) {
+		dev_err(dev, "failed to unregister notifier\n");
+		return ret;
+	}
+
+	cec_unregister_adapter(cros_ec_cec->adap);
+
+	if (cros_ec_cec->notify)
+		cec_notifier_put(cros_ec_cec->notify);
+
+	return 0;
+}
+
+static struct platform_driver cros_ec_cec_driver = {
+	.probe = cros_ec_cec_probe,
+	.remove  = cros_ec_cec_remove,
+	.driver = {
+		.name = DRV_NAME,
+		.pm = &cros_ec_cec_pm_ops,
+	},
+};
+
+module_platform_driver(cros_ec_cec_driver);
+
+MODULE_DESCRIPTION("CEC driver for ChromeOS ECs");
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
-- 
2.7.4

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Hans Verkuil]

On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Hi All,
> 
> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> through it's Embedded Controller, to enable the Linux CEC Core to communicate
> with it and get the CEC Physical Address from the correct HDMI Connector, the
> following must be added/changed:
> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
> - Add the CEC related commands and events definitions into the EC MFD driver
> - Add a way to get a CEC notifier with it's (optional) connector name
> - Add the CEC notifier to the i915 HDMI driver
> - Add the proper ChromeOS EC CEC Driver
> 
> The CEC notifier with the connector name is the tricky point, since even on
> Device-Tree platforms, there is no way to distinguish between multiple HDMI
> connectors from the same DRM driver. The solution I implemented is pretty
> simple and only adds an optional connector name to eventually distinguish
> an HDMI connector notifier from another if they share the same device.

This looks good to me, which brings me to the next question: how to merge
this?

It touches on three subsystems (media, drm, mfd), so that makes this
tricky.

I think there are two options: either the whole series goes through the
media tree, or patches 1+2 go through drm and 3-6 through media. If there
is a high chance of conflicts in the mfd code, then it is also an option to
have patches 3-6 go through the mfd subsystem.

Any opinions?

Regards,

	Hans

> 
> Feel free to comment this patchset !
> 
> Changes since v6:
> - Added stable identifier comment in intel_display.h
> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h
> - Added Acked-by/Reviewed-By tags
> 
> Changes since v5:
>  - Small fixups on include/linux/mfd/cros_ec_commands.h
>  - Fixed on cros-ec-cec driver accordingly
>  - Added Reviewed-By tags
> 
> Changes since v4:
>  - Split patch 3 to move the mkbp event size change into a separate patch
> 
> Changes since v3 (incorrectly reported as v2):
>  - Renamed "Chrome OS" to "ChromeOS"
>  - Updated cros_ec_commands.h new structs definitions to kernel doc format
>  - Added Reviewed-By tags
> 
> Changes since v2:
>  - Add i915 port_identifier() and use this stable name as cec_notifier conn name
>  - Fixed and cleaned up the CEC commands and events handling
>  - Rebased the CEC sub-device registration on top of Enric's serie
>  - Fixed comments typo on cec driver
>  - Protected the DMI match only with PCI and DMI Kconfigs
> 
> Changes since v1:
>  - Added cec_notifier_put to intel_hdmi
>  - Fixed all small reported issues on the EC CEC driver
>  - Moved the cec_notifier_get out of the #if .. #else .. #endif
> 
> Changes since RFC:
>  - Moved CEC sub-device registration after CEC commands and events definitions patch
>  - Removed get_notifier_get_byname
>  - Added CEC_CORE select into i915 Kconfig
>  - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn
>  - Fixed CEC core return type on error
>  - Moved to cros-ec-cec media platform directory
>  - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname()
>  - Fix Logical Address setup
>  - Added comment about HW support
>  - Removed memset of msg structures
> 
> Neil Armstrong (6):
>   media: cec-notifier: Get notifier by device and connector name
>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>   mfd: cros-ec: Increase maximum mkbp event size
>   mfd: cros-ec: Introduce CEC commands and events definitions.
>   mfd: cros_ec_dev: Add CEC sub-device registration
>   media: platform: Add ChromeOS EC CEC driver
> 
>  drivers/gpu/drm/i915/Kconfig                     |   1 +
>  drivers/gpu/drm/i915/intel_display.h             |  24 ++
>  drivers/gpu/drm/i915/intel_drv.h                 |   2 +
>  drivers/gpu/drm/i915/intel_hdmi.c                |  13 +
>  drivers/media/cec/cec-notifier.c                 |  11 +-
>  drivers/media/platform/Kconfig                   |  11 +
>  drivers/media/platform/Makefile                  |   2 +
>  drivers/media/platform/cros-ec-cec/Makefile      |   1 +
>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++++++++++++++++++++++
>  drivers/mfd/cros_ec_dev.c                        |  16 ++
>  drivers/platform/chrome/cros_ec_proto.c          |  40 ++-
>  include/linux/mfd/cros_ec.h                      |   2 +-
>  include/linux/mfd/cros_ec_commands.h             | 100 +++++++
>  include/media/cec-notifier.h                     |  27 +-
>  14 files changed, 581 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> 

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Neil Armstrong]

Hi Hans,

On 08/06/2018 09:53, Hans Verkuil wrote:
> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>> Hi All,
>>
>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>> with it and get the CEC Physical Address from the correct HDMI Connector, the
>> following must be added/changed:
>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
>> - Add the CEC related commands and events definitions into the EC MFD driver
>> - Add a way to get a CEC notifier with it's (optional) connector name
>> - Add the CEC notifier to the i915 HDMI driver
>> - Add the proper ChromeOS EC CEC Driver
>>
>> The CEC notifier with the connector name is the tricky point, since even on
>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
>> connectors from the same DRM driver. The solution I implemented is pretty
>> simple and only adds an optional connector name to eventually distinguish
>> an HDMI connector notifier from another if they share the same device.
> 
> This looks good to me, which brings me to the next question: how to merge
> this?
> 
> It touches on three subsystems (media, drm, mfd), so that makes this
> tricky.
> 
> I think there are two options: either the whole series goes through the
> media tree, or patches 1+2 go through drm and 3-6 through media. If there
> is a high chance of conflicts in the mfd code, then it is also an option to
> have patches 3-6 go through the mfd subsystem.

I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
then I think the rest could go in the media tree.

Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?

Could we have an immutable branch from media tree with patch 1 to be merged in
the i915 tree for patch 2 ?

Or patch 1+2 could me merged into the i915 tree and generate an immutable branch
for media to merge the mfd branch + patch 7 ?

Neil

> 
> Any opinions?
> 
> Regards,
> 
> 	Hans
> 
>>
>> Feel free to comment this patchset !
>>
>> Changes since v6:
>> - Added stable identifier comment in intel_display.h
>> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h
>> - Added Acked-by/Reviewed-By tags
>>
>> Changes since v5:
>>  - Small fixups on include/linux/mfd/cros_ec_commands.h
>>  - Fixed on cros-ec-cec driver accordingly
>>  - Added Reviewed-By tags
>>
>> Changes since v4:
>>  - Split patch 3 to move the mkbp event size change into a separate patch
>>
>> Changes since v3 (incorrectly reported as v2):
>>  - Renamed "Chrome OS" to "ChromeOS"
>>  - Updated cros_ec_commands.h new structs definitions to kernel doc format
>>  - Added Reviewed-By tags
>>
>> Changes since v2:
>>  - Add i915 port_identifier() and use this stable name as cec_notifier conn name
>>  - Fixed and cleaned up the CEC commands and events handling
>>  - Rebased the CEC sub-device registration on top of Enric's serie
>>  - Fixed comments typo on cec driver
>>  - Protected the DMI match only with PCI and DMI Kconfigs
>>
>> Changes since v1:
>>  - Added cec_notifier_put to intel_hdmi
>>  - Fixed all small reported issues on the EC CEC driver
>>  - Moved the cec_notifier_get out of the #if .. #else .. #endif
>>
>> Changes since RFC:
>>  - Moved CEC sub-device registration after CEC commands and events definitions patch
>>  - Removed get_notifier_get_byname
>>  - Added CEC_CORE select into i915 Kconfig
>>  - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn
>>  - Fixed CEC core return type on error
>>  - Moved to cros-ec-cec media platform directory
>>  - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname()
>>  - Fix Logical Address setup
>>  - Added comment about HW support
>>  - Removed memset of msg structures
>>
>> Neil Armstrong (6):
>>   media: cec-notifier: Get notifier by device and connector name
>>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>>   mfd: cros-ec: Increase maximum mkbp event size
>>   mfd: cros-ec: Introduce CEC commands and events definitions.
>>   mfd: cros_ec_dev: Add CEC sub-device registration
>>   media: platform: Add ChromeOS EC CEC driver
>>
>>  drivers/gpu/drm/i915/Kconfig                     |   1 +
>>  drivers/gpu/drm/i915/intel_display.h             |  24 ++
>>  drivers/gpu/drm/i915/intel_drv.h                 |   2 +
>>  drivers/gpu/drm/i915/intel_hdmi.c                |  13 +
>>  drivers/media/cec/cec-notifier.c                 |  11 +-
>>  drivers/media/platform/Kconfig                   |  11 +
>>  drivers/media/platform/Makefile                  |   2 +
>>  drivers/media/platform/cros-ec-cec/Makefile      |   1 +
>>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++++++++++++++++++++++
>>  drivers/mfd/cros_ec_dev.c                        |  16 ++
>>  drivers/platform/chrome/cros_ec_proto.c          |  40 ++-
>>  include/linux/mfd/cros_ec.h                      |   2 +-
>>  include/linux/mfd/cros_ec_commands.h             | 100 +++++++
>>  include/media/cec-notifier.h                     |  27 +-
>>  14 files changed, 581 insertions(+), 16 deletions(-)
>>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>>
> 

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Hans Verkuil]

On 08/06/18 10:17, Neil Armstrong wrote:
> Hi Hans,
> 
> On 08/06/2018 09:53, Hans Verkuil wrote:
>> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>>> Hi All,
>>>
>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>>> with it and get the CEC Physical Address from the correct HDMI Connector, the
>>> following must be added/changed:
>>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
>>> - Add the CEC related commands and events definitions into the EC MFD driver
>>> - Add a way to get a CEC notifier with it's (optional) connector name
>>> - Add the CEC notifier to the i915 HDMI driver
>>> - Add the proper ChromeOS EC CEC Driver
>>>
>>> The CEC notifier with the connector name is the tricky point, since even on
>>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
>>> connectors from the same DRM driver. The solution I implemented is pretty
>>> simple and only adds an optional connector name to eventually distinguish
>>> an HDMI connector notifier from another if they share the same device.
>>
>> This looks good to me, which brings me to the next question: how to merge
>> this?
>>
>> It touches on three subsystems (media, drm, mfd), so that makes this
>> tricky.
>>
>> I think there are two options: either the whole series goes through the
>> media tree, or patches 1+2 go through drm and 3-6 through media. If there
>> is a high chance of conflicts in the mfd code, then it is also an option to
>> have patches 3-6 go through the mfd subsystem.
> 
> I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
> then I think the rest could go in the media tree.
> 
> Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?
> 
> Could we have an immutable branch from media tree with patch 1 to be merged in
> the i915 tree for patch 2 ?
> 
> Or patch 1+2 could me merged into the i915 tree and generate an immutable branch

I think patches 1+2 can just go to the i915 tree. The i915 driver changes often,
so going through that tree makes sense. The cec-notifier code is unlikely to change,
and I am fine with that patch going through i915.

> for media to merge the mfd branch + patch 7 ?

Patch 7? I only count 6?

If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all.
There is chance of a conflict when this is eventually pushed to mainline for
the media Kconfig, but that's all.

Regards,

	Hans

> 
> Neil
> 
>>
>> Any opinions?
>>
>> Regards,
>>
>> 	Hans
>>
>>>
>>> Feel free to comment this patchset !
>>>
>>> Changes since v6:
>>> - Added stable identifier comment in intel_display.h
>>> - Renamed to cec_notifier in intel_hdmi.c/intel_drv.h
>>> - Added Acked-by/Reviewed-By tags
>>>
>>> Changes since v5:
>>>  - Small fixups on include/linux/mfd/cros_ec_commands.h
>>>  - Fixed on cros-ec-cec driver accordingly
>>>  - Added Reviewed-By tags
>>>
>>> Changes since v4:
>>>  - Split patch 3 to move the mkbp event size change into a separate patch
>>>
>>> Changes since v3 (incorrectly reported as v2):
>>>  - Renamed "Chrome OS" to "ChromeOS"
>>>  - Updated cros_ec_commands.h new structs definitions to kernel doc format
>>>  - Added Reviewed-By tags
>>>
>>> Changes since v2:
>>>  - Add i915 port_identifier() and use this stable name as cec_notifier conn name
>>>  - Fixed and cleaned up the CEC commands and events handling
>>>  - Rebased the CEC sub-device registration on top of Enric's serie
>>>  - Fixed comments typo on cec driver
>>>  - Protected the DMI match only with PCI and DMI Kconfigs
>>>
>>> Changes since v1:
>>>  - Added cec_notifier_put to intel_hdmi
>>>  - Fixed all small reported issues on the EC CEC driver
>>>  - Moved the cec_notifier_get out of the #if .. #else .. #endif
>>>
>>> Changes since RFC:
>>>  - Moved CEC sub-device registration after CEC commands and events definitions patch
>>>  - Removed get_notifier_get_byname
>>>  - Added CEC_CORE select into i915 Kconfig
>>>  - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn
>>>  - Fixed CEC core return type on error
>>>  - Moved to cros-ec-cec media platform directory
>>>  - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname()
>>>  - Fix Logical Address setup
>>>  - Added comment about HW support
>>>  - Removed memset of msg structures
>>>
>>> Neil Armstrong (6):
>>>   media: cec-notifier: Get notifier by device and connector name
>>>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>>>   mfd: cros-ec: Increase maximum mkbp event size
>>>   mfd: cros-ec: Introduce CEC commands and events definitions.
>>>   mfd: cros_ec_dev: Add CEC sub-device registration
>>>   media: platform: Add ChromeOS EC CEC driver
>>>
>>>  drivers/gpu/drm/i915/Kconfig                     |   1 +
>>>  drivers/gpu/drm/i915/intel_display.h             |  24 ++
>>>  drivers/gpu/drm/i915/intel_drv.h                 |   2 +
>>>  drivers/gpu/drm/i915/intel_hdmi.c                |  13 +
>>>  drivers/media/cec/cec-notifier.c                 |  11 +-
>>>  drivers/media/platform/Kconfig                   |  11 +
>>>  drivers/media/platform/Makefile                  |   2 +
>>>  drivers/media/platform/cros-ec-cec/Makefile      |   1 +
>>>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++++++++++++++++++++++
>>>  drivers/mfd/cros_ec_dev.c                        |  16 ++
>>>  drivers/platform/chrome/cros_ec_proto.c          |  40 ++-
>>>  include/linux/mfd/cros_ec.h                      |   2 +-
>>>  include/linux/mfd/cros_ec_commands.h             | 100 +++++++
>>>  include/media/cec-notifier.h                     |  27 +-
>>>  14 files changed, 581 insertions(+), 16 deletions(-)
>>>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>>>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>>>
>>
> 

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Lee Jones]

On Fri, 08 Jun 2018, Hans Verkuil wrote:
> On 08/06/18 10:17, Neil Armstrong wrote:
> > On 08/06/2018 09:53, Hans Verkuil wrote:
> >> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> >>> Hi All,
> >>>
> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> >>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
> >>> with it and get the CEC Physical Address from the correct HDMI Connector, the
> >>> following must be added/changed:
> >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
> >>> - Add the CEC related commands and events definitions into the EC MFD driver
> >>> - Add a way to get a CEC notifier with it's (optional) connector name
> >>> - Add the CEC notifier to the i915 HDMI driver
> >>> - Add the proper ChromeOS EC CEC Driver
> >>>
> >>> The CEC notifier with the connector name is the tricky point, since even on
> >>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
> >>> connectors from the same DRM driver. The solution I implemented is pretty
> >>> simple and only adds an optional connector name to eventually distinguish
> >>> an HDMI connector notifier from another if they share the same device.
> >>
> >> This looks good to me, which brings me to the next question: how to merge
> >> this?
> >>
> >> It touches on three subsystems (media, drm, mfd), so that makes this
> >> tricky.
> >>
> >> I think there are two options: either the whole series goes through the
> >> media tree, or patches 1+2 go through drm and 3-6 through media. If there
> >> is a high chance of conflicts in the mfd code, then it is also an option to
> >> have patches 3-6 go through the mfd subsystem.
> > 
> > I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
> > then I think the rest could go in the media tree.
> > 
> > Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?
> > 
> > Could we have an immutable branch from media tree with patch 1 to be merged in
> > the i915 tree for patch 2 ?
> > 
> > Or patch 1+2 could me merged into the i915 tree and generate an immutable branch
> 
> I think patches 1+2 can just go to the i915 tree. The i915 driver changes often,
> so going through that tree makes sense. The cec-notifier code is unlikely to change,
> and I am fine with that patch going through i915.
> 
> > for media to merge the mfd branch + patch 7 ?
> 
> Patch 7? I only count 6?
> 
> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all.
> There is chance of a conflict when this is eventually pushed to mainline for
> the media Kconfig, but that's all.

What are the *build* dependencies within the set?

I'd be happy to send out a pull-request for either all of the patches,
or just the MFD changes once I've had chance to review them.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Neil Armstrong]

Hi Lee,

On 11/06/2018 08:03, Lee Jones wrote:
> On Fri, 08 Jun 2018, Hans Verkuil wrote:
>> On 08/06/18 10:17, Neil Armstrong wrote:
>>> On 08/06/2018 09:53, Hans Verkuil wrote:
>>>> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>>>>> Hi All,
>>>>>
>>>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>>>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>>>>> with it and get the CEC Physical Address from the correct HDMI Connector, the
>>>>> following must be added/changed:
>>>>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
>>>>> - Add the CEC related commands and events definitions into the EC MFD driver
>>>>> - Add a way to get a CEC notifier with it's (optional) connector name
>>>>> - Add the CEC notifier to the i915 HDMI driver
>>>>> - Add the proper ChromeOS EC CEC Driver
>>>>>
>>>>> The CEC notifier with the connector name is the tricky point, since even on
>>>>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
>>>>> connectors from the same DRM driver. The solution I implemented is pretty
>>>>> simple and only adds an optional connector name to eventually distinguish
>>>>> an HDMI connector notifier from another if they share the same device.
>>>>
>>>> This looks good to me, which brings me to the next question: how to merge
>>>> this?
>>>>
>>>> It touches on three subsystems (media, drm, mfd), so that makes this
>>>> tricky.
>>>>
>>>> I think there are two options: either the whole series goes through the
>>>> media tree, or patches 1+2 go through drm and 3-6 through media. If there
>>>> is a high chance of conflicts in the mfd code, then it is also an option to
>>>> have patches 3-6 go through the mfd subsystem.
>>>
>>> I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
>>> then I think the rest could go in the media tree.
>>>
>>> Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?
>>>
>>> Could we have an immutable branch from media tree with patch 1 to be merged in
>>> the i915 tree for patch 2 ?
>>>
>>> Or patch 1+2 could me merged into the i915 tree and generate an immutable branch
>>
>> I think patches 1+2 can just go to the i915 tree. The i915 driver changes often,
>> so going through that tree makes sense. The cec-notifier code is unlikely to change,
>> and I am fine with that patch going through i915.
>>
>>> for media to merge the mfd branch + patch 7 ?
>>
>> Patch 7? I only count 6?
>>
>> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all.
>> There is chance of a conflict when this is eventually pushed to mainline for
>> the media Kconfig, but that's all.
> 
> What are the *build* dependencies within the set?

Here are the hard the build dependency :

Patch 2 depends on Patch 1
Patch 5 depends on Patch 4
Patch 6 depends on Patches 1 & 4

> 
> I'd be happy to send out a pull-request for either all of the patches,
> or just the MFD changes once I've had chance to review them.
> 

Great, thanks !

Neil

Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

[Hans Verkuil]

On 11/06/18 10:56, Neil Armstrong wrote:
> Hi Lee,
> 
> On 11/06/2018 08:03, Lee Jones wrote:
>> On Fri, 08 Jun 2018, Hans Verkuil wrote:
>>> On 08/06/18 10:17, Neil Armstrong wrote:
>>>> On 08/06/2018 09:53, Hans Verkuil wrote:
>>>>> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>>>>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>>>>>> with it and get the CEC Physical Address from the correct HDMI Connector, the
>>>>>> following must be added/changed:
>>>>>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
>>>>>> - Add the CEC related commands and events definitions into the EC MFD driver
>>>>>> - Add a way to get a CEC notifier with it's (optional) connector name
>>>>>> - Add the CEC notifier to the i915 HDMI driver
>>>>>> - Add the proper ChromeOS EC CEC Driver
>>>>>>
>>>>>> The CEC notifier with the connector name is the tricky point, since even on
>>>>>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
>>>>>> connectors from the same DRM driver. The solution I implemented is pretty
>>>>>> simple and only adds an optional connector name to eventually distinguish
>>>>>> an HDMI connector notifier from another if they share the same device.
>>>>>
>>>>> This looks good to me, which brings me to the next question: how to merge
>>>>> this?
>>>>>
>>>>> It touches on three subsystems (media, drm, mfd), so that makes this
>>>>> tricky.
>>>>>
>>>>> I think there are two options: either the whole series goes through the
>>>>> media tree, or patches 1+2 go through drm and 3-6 through media. If there
>>>>> is a high chance of conflicts in the mfd code, then it is also an option to
>>>>> have patches 3-6 go through the mfd subsystem.
>>>>
>>>> I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
>>>> then I think the rest could go in the media tree.
>>>>
>>>> Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?
>>>>
>>>> Could we have an immutable branch from media tree with patch 1 to be merged in
>>>> the i915 tree for patch 2 ?
>>>>
>>>> Or patch 1+2 could me merged into the i915 tree and generate an immutable branch
>>>
>>> I think patches 1+2 can just go to the i915 tree. The i915 driver changes often,
>>> so going through that tree makes sense. The cec-notifier code is unlikely to change,
>>> and I am fine with that patch going through i915.
>>>
>>>> for media to merge the mfd branch + patch 7 ?
>>>
>>> Patch 7? I only count 6?
>>>
>>> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all.
>>> There is chance of a conflict when this is eventually pushed to mainline for
>>> the media Kconfig, but that's all.
>>
>> What are the *build* dependencies within the set?
> 
> Here are the hard the build dependency :
> 
> Patch 2 depends on Patch 1
> Patch 5 depends on Patch 4
> Patch 6 depends on Patches 1 & 4

Ah, I missed the dependency of patch 6 on patch 1. So the whole series needs
to be merged as a single unit.

> 
>>
>> I'd be happy to send out a pull-request for either all of the patches,
>> or just the MFD changes once I've had chance to review them.
>>
> 
> Great, thanks !
> 
> Neil
> 

I'm OK if this goes through the mfd tree.

Regards,

	Hans