Re: [PATCH v3 2/3] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER

2024-05-22 Thread Neil Armstrong

On 22/05/2024 08:25, Dmitry Baryshkov wrote:

This panel driver uses DSC PPS functions and as such depends on the
DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions
available to the driver.

Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/panel/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4a2f621433ef..3e3f63479544 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -340,6 +340,8 @@ config DRM_PANEL_LG_SW43408
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
+   select DRM_DISPLAY_DSC_HELPER
+   select DRM_DISPLAY_HELPER
help
  Say Y here if you want to enable support for LG sw43408 panel.
  The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per



Reviewed-by: Neil Armstrong 


Re: [PATCH v3 3/3] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static

2024-05-22 Thread Neil Armstrong

On 22/05/2024 08:25, Dmitry Baryshkov wrote:

Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.

Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Reviewed-by: Neil Armstrong 
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c 
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct 
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
  }
  
-const struct backlight_ops sw43408_backlight_ops = {

+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
  };
  



Reviewed-by: Neil Armstrong 


Re: [PATCH 7/8] drm/bridge: lt9611uxc: use int for holding number of modes

2024-03-11 Thread Neil Armstrong

On 08/03/2024 17:03, Jani Nikula wrote:

lt9611uxc_connector_get_modes() propagates the return value of
drm_edid_connector_add_modes() but stores the int temporarily in an
unsigned int. Use the correct type.

Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Robert Foss 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index bcf8bccd86d6..f4f593ad8f79 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -294,8 +294,8 @@ static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct 
lt9611uxc *lt9611uxc,
  static int lt9611uxc_connector_get_modes(struct drm_connector *connector)
  {
struct lt9611uxc *lt9611uxc = connector_to_lt9611uxc(connector);
-   unsigned int count;
const struct drm_edid *drm_edid;
+   int count;
  
  	drm_edid = drm_bridge_edid_read(>bridge, connector);

drm_edid_connector_update(connector, drm_edid);


Reviewed-by: Neil Armstrong 


Re: [PATCH 2/8] drm/panel: do not return negative error codes from drm_panel_get_modes()

2024-03-11 Thread Neil Armstrong

On 08/03/2024 17:03, Jani Nikula wrote:

None of the callers of drm_panel_get_modes() expect it to return
negative error codes. Either they propagate the return value in their
struct drm_connector_helper_funcs .get_modes() hook (which is also not
supposed to return negative codes), or add it to other counts leading to
bogus values.

On the other hand, many of the struct drm_panel_funcs .get_modes() hooks
do return negative error codes, so handle them gracefully instead of
propagating further.

Return 0 for no modes, whatever the reason.

Cc: Neil Armstrong 
Cc: Jessica Zhang 
Cc: Sam Ravnborg 
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/drm_panel.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index e814020bbcd3..cfbe020de54e 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -274,19 +274,24 @@ EXPORT_SYMBOL(drm_panel_disable);
   * The modes probed from the panel are automatically added to the connector
   * that the panel is attached to.
   *
- * Return: The number of modes available from the panel on success or a
- * negative error code on failure.
+ * Return: The number of modes available from the panel on success, or 0 on
+ * failure (no modes).
   */
  int drm_panel_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
  {
if (!panel)
-   return -EINVAL;
+   return 0;
  
-	if (panel->funcs && panel->funcs->get_modes)

-   return panel->funcs->get_modes(panel, connector);
+   if (panel->funcs && panel->funcs->get_modes) {
+   int num;
  
-	return -EOPNOTSUPP;

+   num = panel->funcs->get_modes(panel, connector);
+   if (num > 0)
+   return num;
+   }
+
+   return 0;
  }
  EXPORT_SYMBOL(drm_panel_get_modes);
  


Reviewed-by: Neil Armstrong 


Re: [Intel-gfx] [PATCH] MAINTAINERS: drm/ci: add entries for xfail files

2023-10-02 Thread neil . armstrong

On 19/09/2023 20:22, Helen Koike wrote:

DRM CI keeps track of which tests are failing, flaking or being skipped
by the ci in the expectations files. Add entries for those files to the
corresponding driver maintainer, so they can be notified when they
change.

Signed-off-by: Helen Koike 
---

For reference: 
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg463165.html

  MAINTAINERS | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90f13281d297..740a2ce2689c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6614,6 +6614,7 @@ S:Maintained
  B:https://gitlab.freedesktop.org/drm/msm/-/issues
  T:git https://gitlab.freedesktop.org/drm/msm.git
  F:Documentation/devicetree/bindings/display/msm/
+F: drivers/gpu/drm/ci/xfails/msm*
  F:drivers/gpu/drm/msm/
  F:include/uapi/drm/msm_drm.h
  
@@ -6886,6 +6887,7 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc

  F:Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
  F:Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
  F:Documentation/gpu/meson.rst
+F: drivers/gpu/drm/ci/xfails/meson*
  F:drivers/gpu/drm/meson/
  
  DRM DRIVERS FOR ATMEL HLCDC

@@ -6994,6 +6996,7 @@ L:dri-de...@lists.freedesktop.org
  L:linux-media...@lists.infradead.org (moderated for non-subscribers)
  S:Supported
  F:Documentation/devicetree/bindings/display/mediatek/
+F: drivers/gpu/drm/ci/xfails/mediatek*
  F:drivers/gpu/drm/mediatek/
  F:drivers/phy/mediatek/phy-mtk-dp.c
  F:drivers/phy/mediatek/phy-mtk-hdmi*
@@ -7034,6 +7037,7 @@ L:dri-de...@lists.freedesktop.org
  S:Maintained
  T:git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/display/rockchip/
+F: drivers/gpu/drm/ci/xfails/rockchip*
  F:drivers/gpu/drm/rockchip/
  
  DRM DRIVERS FOR STI

@@ -10476,6 +10480,7 @@ C:  irc://irc.oftc.net/intel-gfx
  T:git git://anongit.freedesktop.org/drm-intel
  F:Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
  F:Documentation/gpu/i915.rst
+F: drivers/gpu/drm/ci/xfails/i915*
  F:drivers/gpu/drm/i915/
  F:include/drm/i915*
  F:include/uapi/drm/i915_drm.h
@@ -17862,6 +17867,7 @@ C:  irc://irc.oftc.net/radeon
  T:git https://gitlab.freedesktop.org/agd5f/linux.git
  F:Documentation/gpu/amdgpu/
  F:drivers/gpu/drm/amd/
+F: drivers/gpu/drm/ci/xfails/amd*
  F:drivers/gpu/drm/radeon/
  F:include/uapi/drm/amdgpu_drm.h
  F:include/uapi/drm/radeon_drm.h
@@ -22846,6 +22852,7 @@ L:  dri-de...@lists.freedesktop.org
  L:virtualizat...@lists.linux-foundation.org
  S:Maintained
  T:git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/ci/xfails/virtio*
  F:drivers/gpu/drm/virtio/
  F:include/uapi/linux/virtio_gpu.h
  


Reviewed-by: Neil Armstrong 


Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types

2023-08-02 Thread Neil Armstrong

On 29/07/2023 02:49, Dmitry Baryshkov wrote:

If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/drm_bridge_connector.c | 33 +-
  include/drm/drm_bridge.h   |  4 
  2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 07b5930b1282..a7b92f0d2430 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+   enum drm_mode_subconnector subconnector;
int connector_type;
+   int ret;
  
  	bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);

if (!bridge_connector)
@@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
  
-		if (!drm_bridge_get_next_bridge(bridge))

+   if (!drm_bridge_get_next_bridge(bridge)) {
connector_type = bridge->type;
+   subconnector = bridge->subtype;
+   }
  
  #ifdef CONFIG_OF

if (!drm_bridge_get_next_bridge(bridge) &&
@@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
if (panel_bridge)
drm_panel_bridge_set_orientation(connector, panel_bridge);
  
+	if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {

+   drm_connector_attach_dp_subconnector_property(connector, 
subconnector);
+   } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
+   ret = drm_mode_create_dvi_i_properties(drm);
+   if (ret)
+   return ERR_PTR(ret);
+
+   drm_object_attach_property(>base,
+  
drm->mode_config.dvi_i_subconnector_property,
+  subconnector);
+   } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
+   ret = drm_mode_create_tv_properties(drm,
+   BIT(DRM_MODE_TV_MODE_NTSC) |
+   
BIT(DRM_MODE_TV_MODE_NTSC_443) |
+   
BIT(DRM_MODE_TV_MODE_NTSC_J) |
+   BIT(DRM_MODE_TV_MODE_PAL) |
+   BIT(DRM_MODE_TV_MODE_PAL_M) 
|
+   BIT(DRM_MODE_TV_MODE_PAL_N) 
|
+   
BIT(DRM_MODE_TV_MODE_SECAM));
+   if (ret)
+   return ERR_PTR(ret);


I don't think this is right, this should be called from the appropriate encoder
device depending on the analog tv mode capabilities.



+
+   drm_object_attach_property(>base,
+  
drm->mode_config.tv_subconnector_property,
+  subconnector);


Here, only add the property if drm->mode_config.tv_subconnector_property exists,
and perhaps add a warning if not.

AFAIK same for DRM_MODE_CONNECTOR_DVII.


+   }
+
return connector;
  }
  EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bf964cdfb330..68b14ac5ac0d 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -739,6 +739,10 @@ struct drm_bridge {
 * identifies the type of connected display.
 */
int type;
+   /**
+* @subtype: the subtype of the connector for the DP/TV/DVI-I cases.
+*/
+   enum drm_mode_subconnector subtype;
/**
 * @interlace_allowed: Indicate that the bridge can handle interlaced
 * modes.




Re: [Intel-gfx] [PATCH v3 1/2] drm/probe_helper: extract two helper functions

2023-01-26 Thread Neil Armstrong
Hi,

On Tue, 24 Jan 2023 12:45:47 +0200, Dmitry Baryshkov wrote:
> Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
> two helpers that enable and disable HPD handling on all device's
> connectors.
> 
> 

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[1/2] drm/probe_helper: extract two helper functions
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=cbf143b282c64e59559cc8351c0b5b1ab4bbdcbe
[2/2] drm/probe_helper: sort out poll_running vs poll_enabled
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=d33a54e3991dfce88b4fc6d9c3360951c2c5660d

-- 
Neil



Re: [Intel-gfx] [PATCH v3 2/2] drm/probe_helper: sort out poll_running vs poll_enabled

2023-01-25 Thread Neil Armstrong

Hi,

On 24/01/2023 11:45, Dmitry Baryshkov wrote:

There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.

This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.

This fixes the following warning reported after merging the HPD series:


Seems this patchset is ready to be applied to drm-misc-next, if it's ok
for everyone I'll apply it later today.

Thanks,
Neil



Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257 
drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card 
snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif 
adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : 89ef3740
x29: 89ef3740 x28: 09331f00 x27: 1000
x26: 0020 x25: 81148ed8 x24: 0a8fe000
x23: fffd x22: 05086348 x21: 81133ee0
x20: 0550d800 x19: 05086288 x18: 0006
x17:  x16: 896ef008 x15: 972891004260
x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
x8 : 00250b00 x7 : 0003 x6 : 0011
x5 :  x4 : bd986a48 x3 : 0001
x2 :  x1 :  x0 : 0025
Call trace:
  drm_bridge_hpd_enable+0x94/0x9c [drm]
  drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
  drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
  drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
  drm_client_modeset_probe+0x204/0x1190 [drm]
  __drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
  drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
  drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
  drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
  dcss_kms_attach+0x1c8/0x254 [imx_dcss]
  dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
  platform_probe+0x70/0xcc
  really_probe+0xc4/0x2e0
  __driver_probe_device+0x80/0xf0
  driver_probe_device+0xe0/0x164
  __device_attach_driver+0xc0/0x13c
  bus_for_each_drv+0x84/0xe0
  __device_attach+0xa4/0x1a0
  device_initial_probe+0x1c/0x30
  bus_probe_device+0xa4/0xb0
  deferred_probe_work_func+0x90/0xd0
  process_one_work+0x200/0x474
  worker_thread+0x74/0x43c
  kthread+0xfc/0x110
  ret_from_fork+0x10/0x20
---[ end trace  ]---

Reported-by: Laurentiu Palcu 
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Tested-by: Marek Szyprowski 
Tested-by: Chen-Yu Tsai 
Acked-by: Laurentiu Palcu 
Tested-by: Laurentiu Palcu 
Tested-by: Laurent Pinchart 
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/drm_probe_helper.c | 42 +++---
  1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index ab787d71fa66..8127be134c39 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -282,7 +282,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
bool poll = false;
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
  
-	if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)

+   if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll ||
+   dev->mode_config.poll_running)
return;
  
  	poll = drm_kms_helper_enable_hpd(dev);

@@ -304,6 +305,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
  
  	if (poll)

schedule_delayed_work(>mode_config.output_poll_work, 
delay);
+
+   dev->mode_config.poll_running = true;
  }
  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
  
@@ -592,10 +595,7 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector,

}
  
  	/* Re-enable polling in case the global poll config changed. */

-   if (drm_kms_helper_poll != dev->mode_config.poll_running)
-   drm_kms_helper_poll_enable(dev);
-
-   dev->mode_config.poll_running = drm_kms_helper_poll;
+   drm_kms_helper_poll_enable(dev);
  
  	if (connector->status == connector_status_disconnected) {


Re: [Intel-gfx] [PATCH v3 1/2] drm/probe_helper: extract two helper functions

2023-01-24 Thread Neil Armstrong

On 24/01/2023 11:45, Dmitry Baryshkov wrote:

Extract drm_kms_helper_enable_hpd() and drm_kms_helper_disable_hpd(),
two helpers that enable and disable HPD handling on all device's
connectors.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/drm_probe_helper.c | 68 ++
  1 file changed, 41 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 95aeeed33cf5..ab787d71fa66 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -222,6 +222,45 @@ drm_connector_mode_valid(struct drm_connector *connector,
return ret;
  }
  
+static void drm_kms_helper_disable_hpd(struct drm_device *dev)

+{
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   const struct drm_connector_helper_funcs *funcs =
+   connector->helper_private;
+
+   if (funcs && funcs->disable_hpd)
+   funcs->disable_hpd(connector);
+   }
+   drm_connector_list_iter_end(_iter);
+}
+
+static bool drm_kms_helper_enable_hpd(struct drm_device *dev)
+{
+   bool poll = false;
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   const struct drm_connector_helper_funcs *funcs =
+   connector->helper_private;
+
+   if (funcs && funcs->enable_hpd)
+   funcs->enable_hpd(connector);
+
+   if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
+DRM_CONNECTOR_POLL_DISCONNECT))
+   poll = true;
+   }
+   drm_connector_list_iter_end(_iter);
+
+   return poll;
+}
+
  #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
  /**
   * drm_kms_helper_poll_enable - re-enable output polling.
@@ -241,26 +280,12 @@ drm_connector_mode_valid(struct drm_connector *connector,
  void drm_kms_helper_poll_enable(struct drm_device *dev)
  {
bool poll = false;
-   struct drm_connector *connector;
-   struct drm_connector_list_iter conn_iter;
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
  
  	if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)

return;
  
-	drm_connector_list_iter_begin(dev, _iter);

-   drm_for_each_connector_iter(connector, _iter) {
-   const struct drm_connector_helper_funcs *funcs =
-   connector->helper_private;
-
-   if (funcs && funcs->enable_hpd)
-   funcs->enable_hpd(connector);
-
-   if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
-DRM_CONNECTOR_POLL_DISCONNECT))
-   poll = true;
-   }
-   drm_connector_list_iter_end(_iter);
+   poll = drm_kms_helper_enable_hpd(dev);
  
  	if (dev->mode_config.delayed_event) {

/*
@@ -810,24 +835,13 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
  
  static void drm_kms_helper_poll_disable_fini(struct drm_device *dev, bool fini)

  {
-   struct drm_connector *connector;
-   struct drm_connector_list_iter conn_iter;
-
if (!dev->mode_config.poll_enabled)
return;
  
  	if (fini)

dev->mode_config.poll_enabled = false;
  
-	drm_connector_list_iter_begin(dev, _iter);

-   drm_for_each_connector_iter(connector, _iter) {
-   const struct drm_connector_helper_funcs *funcs =
-   connector->helper_private;
-
-   if (funcs && funcs->disable_hpd)
-   funcs->disable_hpd(connector);
-   }
-   drm_connector_list_iter_end(_iter);
+   drm_kms_helper_disable_hpd(dev);
  
  	cancel_delayed_work_sync(>mode_config.output_poll_work);

  }


Reviewed-by: Neil Armstrong 


Re: [Intel-gfx] [PATCH 01/13] drm/connector: Add define for HDMI 1.4 Maximum Pixel Rate

2021-11-03 Thread Neil Armstrong
On 02/11/2021 15:59, Maxime Ripard wrote:
> A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
> driver to test whether the resolutions are supported or if the
> scrambling needs to be enabled.
> 
> Let's create a common define for everyone to use it.
> 
> Cc: Alex Deucher 
> Cc: amd-...@lists.freedesktop.org
> Cc: Andrzej Hajda 
> Cc: Benjamin Gaignard 
> Cc: "Christian König" 
> Cc: Emma Anholt 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Jernej Skrabec 
> Cc: Jerome Brunet 
> Cc: Jonas Karlman 
> Cc: Jonathan Hunter 
> Cc: Joonas Lahtinen 
> Cc: Kevin Hilman 
> Cc: Laurent Pinchart 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> Cc: Martin Blumenstingl 
> Cc: Neil Armstrong 
> Cc: "Pan, Xinhui" 
> Cc: Robert Foss 
> Cc: Rodrigo Vivi 
> Cc: Thierry Reding 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  | 4 ++--
>  drivers/gpu/drm/drm_edid.c | 2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c  | 2 +-
>  drivers/gpu/drm/meson/meson_dw_hdmi.c  | 4 ++--
>  drivers/gpu/drm/radeon/radeon_encoders.c   | 2 +-
>  drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 2 +-
>  drivers/gpu/drm/tegra/sor.c| 8 
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++--
>  include/drm/drm_connector.h| 2 ++
>  9 files changed, 16 insertions(+), 14 deletions(-)

For meson & bridge/synopsys/dw-hdmi:

Acked-by: Neil Armstrong 

> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 62ae63565d3a..3a58db357be0 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -46,7 +46,7 @@
>  /* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
>  #define SCDC_MIN_SOURCE_VERSION  0x1
>  
> -#define HDMI14_MAX_TMDSCLK   34000
> +#define HDMI14_MAX_TMDSCLK   (DRM_HDMI_14_MAX_TMDS_CLK_KHZ * 1000)
>  
>  enum hdmi_datamap {
>   RGB444_8B = 0x01,
> @@ -1264,7 +1264,7 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
>* for low rates is not supported either
>*/
>   if (!display->hdmi.scdc.scrambling.low_rates &&
> - display->max_tmds_clock <= 34)
> + display->max_tmds_clock <= DRM_HDMI_14_MAX_TMDS_CLK_KHZ)
>   return false;
>  
>   return true;
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7aa2a56a71c8..ec8fb2d098ae 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct 
> drm_connector *connector,
>   u32 max_tmds_clock = hf_vsdb[5] * 5000;
>   struct drm_scdc *scdc = >scdc;
>  
> - if (max_tmds_clock > 34) {
> + if (max_tmds_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) {
>   display->max_tmds_clock = max_tmds_clock;
>   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
>   display->max_tmds_clock);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index d2e61f6c6e08..0666203d52b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2226,7 +2226,7 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   if (scdc->scrambling.low_rates)
>   pipe_config->hdmi_scrambling = true;
>  
> - if (pipe_config->port_clock > 34) {
> + if (pipe_config->port_clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ) {
>   pipe_config->hdmi_scrambling = true;
>   pipe_config->hdmi_high_tmds_clock_ratio = true;
>   }
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 0afbd1e70bfc..8078667aea0e 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -434,7 +434,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
> *data,
>   readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>  
>   DRM_DEBUG_DRIVER("\"%s\" div%d\n", mode->name,
> -  mode->clock > 34 ? 40 : 10);
> +  mode->clock > DRM_HDMI_14_MAX_TMDS_CLK_KHZ ? 40 : 10);
>  
>   /* Enable clocks */
>   regm

Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

2021-06-29 Thread Neil Armstrong
Hi,

On 29/06/2021 15:58, Thomas Zimmermann wrote:
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

...

>  drivers/gpu/drm/meson/meson_drv.c |  2 +-

Acked-by: Neil Armstrong 

...

>  
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index a7388bf7c838..3d0ccc7eef1b 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -285,7 +285,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>* Remove early framebuffers (ie. simplefb). The framebuffer can be
>* located anywhere in RAM
>*/
> - ret = drm_aperture_remove_framebuffers(false, "meson-drm-fb");
> + ret = drm_aperture_remove_framebuffers(false, _driver);
>   if (ret)
>   goto free_drm;
>  

...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 00/59] Add support for Keem Bay DRM driver

2020-07-02 Thread Neil Armstrong
Hi,

On 30/06/2020 23:27, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
> 
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC. The SOC's display pipeline is as follows
> 
> +--++-++---+
> |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter |
> +--++-++---+
> 
> LCD controller and Mipi DSI transmitter are part of the SOC and 
> mipi to HDMI converter is ADV7535 for KMB EVM board.
> 
> The DRM driver is a basic KMS atomic modesetting display driver and
> has no 2D or 3D graphics.It calls into the ADV bridge driver at 
> the connector level.
> 
> Only 1080p resolution and single plane is supported at this time.
> The usecase is for debugging video and camera outputs.
> 
> Since we are just starting the upstream process, the KMB EVM board is not in
> mainline and so Device tree changes are missing.

A proper Yaml bindings file is then necessary even if the platform is not
mainline.

Neil

> 
> Anitha Chrisanthus (52):
>   drm/kmb: Add support for KeemBay Display
>   drm/kmb: Added id to kmb_plane
>   drm/kmb: Set correct values in the LAYERn_CFG register
>   drm/kmb: Use biwise operators for register definitions
>   drm/kmb: Updated kmb_plane_atomic_check
>   drm/kmb: Initial check-in for Mipi DSI
>   drm/kmb: Set OUT_FORMAT_CFG register
>   drm/kmb: Added mipi_dsi_host initialization
>   drm/kmb: Part 1 of Mipi Tx Initialization
>   drm/kmb: Part 2 of Mipi Tx Initialization
>   drm/kmb: Use correct mmio offset from data book
>   drm/kmb: Part3 of Mipi Tx initialization
>   drm/kmb: Part4 of Mipi Tx Initialization
>   drm/kmb: Correct address offsets for mipi registers
>   drm/kmb: Part5 of Mipi Tx Intitialization
>   drm/kmb: Part6 of Mipi Tx Initialization
>   drm/kmb: Part7 of Mipi Tx Initialization
>   drm/kmb: Part8 of Mipi Tx Initialization
>   drm/kmb: Added ioremap/iounmap for register access
>   drm/kmb: Register IRQ for LCD
>   drm/kmb: IRQ handlers for LCD and mipi dsi
>   drm/kmb: Set hardcoded values to LCD_VSYNC_START
>   drm/kmb: Additional register programming to update_plane
>   drm/kmb: Add ADV7535 bridge
>   drm/kmb: Display clock enable/disable
>   drm/kmb: rebase to newer kernel version
>   drm/kmb: minor name change to match device tree
>   drm/kmb: Changed MMIO size
>   drm/kmb: Defer Probe
>   drm/kmb: call bridge init in the very beginning
>   drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI
>   drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable
>   drm/kmb: Mipi DPHY initialization changes
>   drm/kmb: Fixed driver unload
>   drm/kmb: Added LCD_TEST config
>   drm/kmb: Changes for LCD to Mipi
>   drm/kmb: Update LCD programming to match MIPI
>   drm/kmb: Changed name of driver to kmb-drm
>   drm/kmb: Mipi settings from input timings
>   drm/kmb: Enable LCD interrupts
>   drm/kmb: Enable LCD interrupts during modeset
>   drm/kmb: Don’t inadvertantly disable LCD controller
>   drm/kmb: SWAP R and B LCD Layer order
>   drm/kmb: Disable ping pong mode
>   drm/kmb: Do the layer initializations only once
>   drm/kmb: disable the LCD layer in EOF irq handler
>   drm/kmb: Initialize uninitialized variables
>   drm/kmb: Added useful messages in LCD ISR
>   kmb/drm: Prune unsupported modes
>   drm/kmb: workaround for dma undeflow issue
>   drm/kmb: Get System Clock from SCMI
>   drm/kmb: work around for planar formats
> 
> Edmund Dea (7):
>   drm/kmb: Cleanup probe functions
>   drm/kmb: Revert dsi_host back to a static variable
>   drm/kmb: Initialize clocks for clk_msscam, clk_mipi_ecfg, &
> clk_mipi_cfg.
>   drm/kmb: Remove declaration of irq_lcd/irq_mipi
>   drm/kmb: Enable MIPI TX HS Test Pattern Generation
>   drm/kmb: Write to LCD_LAYERn_CFG only once
>   drm/kmb: Cleaned up code
> 
>  drivers/gpu/drm/Kconfig |2 +
>  drivers/gpu/drm/Makefile|1 +
>  drivers/gpu/drm/kmb/Kconfig |   12 +
>  drivers/gpu/drm/kmb/Makefile|2 +
>  drivers/gpu/drm/kmb/kmb_crtc.c  |  243 +
>  drivers/gpu/drm/kmb/kmb_crtc.h  |   61 ++
>  drivers/gpu/drm/kmb/kmb_drv.c   |  828 +
>  drivers/gpu/drm/kmb/kmb_drv.h   |  196 
>  drivers/gpu/drm/kmb/kmb_dsi.c   | 1950 
> +++
>  drivers/gpu/drm/kmb/kmb_dsi.h   |  390 
>  drivers/gpu/drm/kmb/kmb_plane.c |  538 +++
>  drivers/gpu/drm/kmb/kmb_plane.h |  142 +++
>  drivers/gpu/drm/kmb/kmb_regs.h  |  758 +++
>  13 files changed, 5123 insertions(+)
>  create mode 100644 drivers/gpu/drm/kmb/Kconfig
>  create mode 100644 drivers/gpu/drm/kmb/Makefile
>  create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
>  create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h
>  create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
>  create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
>  create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
>  

Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device

2020-02-19 Thread Neil Armstrong
Hi,

On 19/02/2020 11:20, Daniel Vetter wrote:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the userspace visible stuff attached to a drm_device can long
> outlive that one (e.g. after a hotunplug while userspace has open
> files and mmap'ed buffers). Give people what they want, but with more
> correctness.
> 
> Mostly copied from devres.c, with types adjusted to fit drm_device and
> a few simplifications - I didn't (yet) copy over everything. Since
> the types don't match code sharing looked like a hopeless endeavour.
> 
> For now it's only super simplified, no groups, you can't remove
> actions (but kfree exists, we'll need that soon). Plus all specific to
> drm_device ofc, including the logging. Which I didn't bother to make
> compile-time optional, since none of the other drm logging is compile
> time optional either.
> 
> One tricky bit here is the chicken between allocating your
> drm_device structure and initiliazing it with drm_dev_init. For
> perfect onion unwinding we'd need to have the action to kfree the
> allocation registered before drm_dev_init registers any of its own
> release handlers. But drm_dev_init doesn't know where exactly the
> drm_device is emebedded into the overall structure, and by the time it
> returns it'll all be too late. And forcing drivers to be able clean up
> everything except the one kzalloc is silly.
> 
> Work around this by having a very special final_kfree pointer. This
> also avoids troubles with the list head possibly disappearing from
> underneath us when we release all resources attached to the
> drm_device.
> 
> v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless
> shuffling while getting everything into shape.
> 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-internals.rst |   6 +
>  drivers/gpu/drm/Makefile|   3 +-
>  drivers/gpu/drm/drm_drv.c   |  13 ++-
>  drivers/gpu/drm/drm_internal.h  |   3 +
>  drivers/gpu/drm/drm_managed.c   | 173 
>  include/drm/drm_device.h|  12 ++
>  include/drm/drm_managed.h   |  25 
>  include/drm/drm_print.h |   6 +
>  8 files changed, 239 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_managed.c
>  create mode 100644 include/drm/drm_managed.h
> 
> diff --git a/Documentation/gpu/drm-internals.rst 
> b/Documentation/gpu/drm-internals.rst
> index a73320576ca9..a6b6145fda78 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder is 
> shared with
>  other BARs, so leaving it mapped could cause undesired behaviour like
>  hangs or memory corruption.
>  
> +Managed Resources
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_managed.c
> +   :doc: managed resources
> +
>  Bus-specific Device Registration and PCI Support
>  
>  
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index ca0ca775d37f..53d8fa170143 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,8 @@ drm-y   :=  drm_auth.o drm_cache.o \
>   drm_plane.o drm_color_mgmt.o drm_print.o \
>   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
>   drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o
> + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
> + drm_managed.o
>  
>  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
> drm_dma.o drm_scatter.o drm_lock.o
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9fcd6ab3c154..3e5627d6eba6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -629,6 +629,9 @@ int drm_dev_init(struct drm_device *dev,
>   dev->dev = get_device(parent);
>   dev->driver = driver;
>  
> + INIT_LIST_HEAD(>managed.resources);
> + spin_lock_init(>managed.lock);
> +
>   /* no per-device feature limits by default */
>   dev->driver_features = ~0u;
>  
> @@ -828,8 +831,16 @@ static void drm_dev_release(struct kref *ref)
>   dev->driver->release(dev);
>   } else {
>   drm_dev_fini(dev);
> - kfree(dev);
> + if (!dev->managed.final_kfree) {
> + WARN_ON(!list_empty(>managed.resources));
> + kfree(dev);
> + }
>   }
> +
> + drm_managed_release(dev);
> +
> + if (dev->managed.final_kfree)
> + kfree(dev->managed.final_kfree);
>  }
>  
>  /**
> diff --git 

Re: [Intel-gfx] [PATCH 35/52] drm/meson: Drop explicit drm_mode_config_cleanup call

2020-02-19 Thread Neil Armstrong
On 19/02/2020 11:21, Daniel Vetter wrote:
> It's right above the drm_dev_put().
> 
> Aside: This driver gets its devm_ stuff all wrong wrt drm_device and
> anything hanging off that. Not the only one unfortunately.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Neil Armstrong 
> Cc: Kevin Hilman 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index b5f5eb7b4bb9..ae94d14ab7bc 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -284,7 +284,9 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>   /* Remove early framebuffers (ie. simplefb) */
>   meson_remove_framebuffers();
>  
> - drm_mode_config_init(drm);
> + ret = drm_mode_config_init(drm);
> + if (ret)
> + goto free_drm;
>   drm->mode_config.max_width = 3840;
>   drm->mode_config.max_height = 2160;
>   drm->mode_config.funcs = _mode_config_funcs;
> @@ -379,7 +381,6 @@ static void meson_drv_unbind(struct device *dev)
>   drm_dev_unregister(drm);
>   drm_irq_uninstall(drm);
>   drm_kms_helper_poll_fini(drm);
> - drm_mode_config_cleanup(drm);
>   drm_dev_put(drm);
>  }
>  
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API

2019-08-19 Thread Neil Armstrong
Hi Dariusz, Hans,

I can apply the dw-hdmi patches if necessary.

Neil

On 19/08/2019 11:38, Hans Verkuil wrote:
> Hi all,
> 
> The patches in this series can be applied independently from each other.
> 
> If you maintain one of these drivers and you want to merge it for v5.4
> yourself, then please do so and let me know. If you prefer I commit it
> to drm-misc, then please review and (hopefully) Ack the patch.
> 
> I would really like to get this in for v5.4 so I can get the userspace
> bits in for v5.4 as well through the media subsystem.
> 
> Dariusz, can you post a v7.1 for patch 5/9 fixing the typo?
> 
> Thanks!
> 
>   Hans
> 
> On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
>> This series updates DRM drivers to use new CEC notifier API.
>>
>> Changes since v6:
>>  Made CEC notifiers' registration and de-registration symmetric
>>  in tda998x and dw-hdmi drivers. Also, accidentally dropped one
>>  patch in v6 (change to drm_dp_cec), brought it back now.
>> Changes since v5:
>> Fixed a warning about a missing comment for a new member of
>>  drm_dp_aux_cec struct. Sending to a wider audience,
>>  including maintainers of respective drivers.
>> Changes since v4:
>>  Addressing review comments.
>> Changes since v3:
>> Updated adapter flags in dw-hdmi-cec.
>> Changes since v2:
>>  Include all DRM patches from "cec: improve notifier support,
>>  add connector info connector info" series.
>> Changes since v1:
>>  Those patches delay creation of notifiers until respective
>>  connectors are constructed. It seems that those patches, for a
>>  couple of drivers, by adding the delay, introduce a race between
>>  notifiers' creation and the IRQs handling threads - at least I
>>  don't see anything obvious in there that would explicitly forbid
>>  such races to occur. v2 adds a write barrier to make sure IRQ
>>  threads see the notifier once it is created (replacing the
>>  WRITE_ONCE I put in v1). The best thing to do here, I believe,
>>  would be not to have any synchronization and make sure that an IRQ
>>  only gets enabled after the notifier is created.
>> Dariusz Marcinkiewicz (9):
>>   drm_dp_cec: add connector info support.
>>   drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
>>   dw-hdmi-cec: use cec_notifier_cec_adap_(un)register
>>   tda9950: use cec_notifier_cec_adap_(un)register
>>   drm: tda998x: use cec_notifier_conn_(un)register
>>   drm: sti: use cec_notifier_conn_(un)register
>>   drm: tegra: use cec_notifier_conn_(un)register
>>   drm: dw-hdmi: use cec_notifier_conn_(un)register
>>   drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
>>
>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +--
>>  drivers/gpu/drm/drm_dp_cec.c  | 25 ++
>>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 31 +++--
>>  drivers/gpu/drm/i2c/tda9950.c | 12 ++---
>>  drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++-
>>  drivers/gpu/drm/i915/display/intel_dp.c   |  4 +-
>>  drivers/gpu/drm/i915/display/intel_hdmi.c | 13 --
>>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  3 +-
>>  drivers/gpu/drm/sti/sti_hdmi.c| 19 +---
>>  drivers/gpu/drm/tegra/output.c| 28 ---
>>  include/drm/drm_dp_helper.h   | 17 ---
>>  13 files changed, 155 insertions(+), 94 deletions(-)
>>
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/13] drm/radeon: Eliminate possible use of an uninitialized variable

2019-08-01 Thread Neil Armstrong
Hi Andrzej,

I had to revert the previous patch, so you should re-spin it entirely :


After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/radeon/radeon_connectors.c: In function 
'radeon_add_legacy_connector':
drivers/gpu/drm/radeon/radeon_connectors.c:2433:5: error: 'ddc' undeclared 
(first use in this function)
 ddc = _connector->ddc_bus->adapter;
 ^~~
drivers/gpu/drm/radeon/radeon_connectors.c:2433:5: note: each undeclared 
identifier is reported only once for each function it appears in

Caused by commit

  bed7a2182de6 ("drm/radeon: Provide ddc symlink in connector sysfs directory")

I have used the drm-misc tree from next-20190731 for today.
==

Neil

On 31/07/2019 18:58, Andrzej Pietrasiewicz wrote:
> ddc local variable is passed to drm_connector_init_with_ddc() and should
> be NULL if no ddc is available.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index b3ad8d890801..d11131d03ed6 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1870,7 +1870,7 @@ radeon_add_atom_connector(struct drm_device *dev,
>   struct radeon_connector_atom_dig *radeon_dig_connector;
>   struct drm_encoder *encoder;
>   struct radeon_encoder *radeon_encoder;
> - struct i2c_adapter *ddc;
> + struct i2c_adapter *ddc = NULL;
>   uint32_t subpixel_order = SubPixelNone;
>   bool shared_ddc = false;
>   bool is_dp_bridge = false;
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Review required [Was: Associate ddc adapters with connectors]

2019-07-31 Thread Neil Armstrong
Hi Andrzej,

On 31/07/2019 16:22, Neil Armstrong wrote:
> On 31/07/2019 15:10, Andrzej Pietrasiewicz wrote:
>> W dniu 31.07.2019 o 12:40, Sam Ravnborg pisze:
>>> Hi Neil.
>>>
>>> On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
>>>> Hi Sam,
>>>>
>>>> On 26/07/2019 20:55, Sam Ravnborg wrote:
>>>>> Hi all.
>>>>>
>>>>> Andrzej have done a good job following up on feedback and this series is
>>>>> now ready.
>>>>>
>>>>> We need ack on the patches touching the individual drivers before we can
>>>>> proceed.
>>>>> Please check your drivers and get back.
>>>>
>>>> I can apply all core and maintainer-acked patches for now :
>>>> 1, 2, 7, 10, 11, 16, 17, 18, 19, 20, 21, 22, 23
>>>>
>>>> and Andrzej can resend not applied patches with Yours and Emil's 
>>>> Reviewed-by,
>>>> so we can wait a few more days to apply them.
>>>
>>> Sounds like a good plan.
>>> Thanks for thaking care of this.
>>
>> When is it good time to resend patches 3, 4, 5, 6, 8, 9, 12, 13, 14, 15, 24 
>> as a
>> new series?
> 
> I'll ping you when everything is applied, build-tested and pushed on 
> drm-misc-next

I pushed 1, 2, 7, 10, 11, 16, 17, 18, 19, 20, 21, 22, 23 :
bed7a2182de6 drm/radeon: Provide ddc symlink in connector sysfs directory
5b50fa2b35a4 drm/amdgpu: Provide ddc symlink in connector sysfs directory
cfb444552926 drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs 
directory
9ebc4d2140ad drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs 
directory
a4f9087e85de drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs 
directory
350fd554ee44 drm/ast: Provide ddc symlink in connector sysfs directory
9572ae176a10 drm/mgag200: Provide ddc symlink in connector sysfs directory
7058e76682d7 drm: sti: Provide ddc symlink in hdmi connector sysfs directory
2ae7eb372ed4 drm/imx: imx-tve: Provide ddc symlink in connector's sysfs
be0ec35940bc drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs
1e8f17855ff8 drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs 
directory
100163df4203 drm: Add drm_connector_init() variant with ddc
e1a29c6c5955 drm: Add ddc link in sysfs created by drm_connector

Neil

> 
> Neil
> 
>>
>> Andrzej
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Review required [Was: Associate ddc adapters with connectors]

2019-07-31 Thread Neil Armstrong
On 31/07/2019 15:10, Andrzej Pietrasiewicz wrote:
> W dniu 31.07.2019 o 12:40, Sam Ravnborg pisze:
>> Hi Neil.
>>
>> On Wed, Jul 31, 2019 at 10:00:14AM +0200, Neil Armstrong wrote:
>>> Hi Sam,
>>>
>>> On 26/07/2019 20:55, Sam Ravnborg wrote:
>>>> Hi all.
>>>>
>>>> Andrzej have done a good job following up on feedback and this series is
>>>> now ready.
>>>>
>>>> We need ack on the patches touching the individual drivers before we can
>>>> proceed.
>>>> Please check your drivers and get back.
>>>
>>> I can apply all core and maintainer-acked patches for now :
>>> 1, 2, 7, 10, 11, 16, 17, 18, 19, 20, 21, 22, 23
>>>
>>> and Andrzej can resend not applied patches with Yours and Emil's 
>>> Reviewed-by,
>>> so we can wait a few more days to apply them.
>>
>> Sounds like a good plan.
>> Thanks for thaking care of this.
> 
> When is it good time to resend patches 3, 4, 5, 6, 8, 9, 12, 13, 14, 15, 24 
> as a
> new series?

I'll ping you when everything is applied, build-tested and pushed on 
drm-misc-next

Neil

> 
> Andrzej

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Review required [Was: Associate ddc adapters with connectors]

2019-07-31 Thread Neil Armstrong
Hi Sam,

On 26/07/2019 20:55, Sam Ravnborg wrote:
> Hi all.
> 
> Andrzej have done a good job following up on feedback and this series is
> now ready.
> 
> We need ack on the patches touching the individual drivers before we can
> proceed.
> Please check your drivers and get back.

I can apply all core and maintainer-acked patches for now :
1, 2, 7, 10, 11, 16, 17, 18, 19, 20, 21, 22, 23

and Andrzej can resend not applied patches with Yours and Emil's Reviewed-by,
so we can wait a few more days to apply them.

Neil

> 
>   Sam
> 
>> Hi Andezej.
>>
>> On Fri, Jul 26, 2019 at 07:22:54PM +0200, Andrzej Pietrasiewicz wrote:
>>> It is difficult for a user to know which of the i2c adapters is for which
>>> drm connector. This series addresses this problem.
>>>
>>> The idea is to have a symbolic link in connector's sysfs directory, e.g.:
>>>
>>> ls -l /sys/class/drm/card0-HDMI-A-1/ddc
>>> lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
>>> -> ../../../../soc/1388.i2c/i2c-2
>>>
>>> The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run
>>> ddcutil:
>>>
>>> ddcutil -b 2 getvcp 0x10
>>> VCP code 0x10 (Brightness): current value =90, max value =   100
>>>
>>> The first patch in the series adds struct i2c_adapter pointer to struct
>>> drm_connector. If the field is used by a particular driver, then an
>>> appropriate symbolic link is created by the generic code, which is also 
>>> added
>>> by this patch.
>>>
>>> Patch 2 adds a new variant of drm_connector_init(), see the changelog
>>> below.
>>>
>>> Patches 3..24 are examples of how to convert a driver to this new scheme.
>>>
>> ...
>>>
>>> v5..v6:
>>>
>>> - improved subject line of patch 1
>>> - added kernel-doc for drm_connector_init_with_ddc()
>>> - improved kernel-doc for the ddc field of struct drm_connector
>>> - added Reviewed-by in patches 17 and 18
>>> - added Acked-by in patch 2
>>> - made the ownership of ddc i2c_adapter explicit in all patches,
>>> this made the affected patches much simpler
>>
>> Looks good now.
>> Patch 1 and 2 are:
>> Reviewed-by: Sam Ravnborg 
>>
>> The remaining patches are:
>> Acked-by: Sam Ravnborg 
>>
>>  Sam
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 19/23] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory

2019-07-31 Thread Neil Armstrong
Hi,

On 30/07/2019 19:30, Sam Ravnborg wrote:
> Hi Neil.
> 
>>> Signed-off-by: Andrzej Pietrasiewicz 
>>> ---
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +++
>>>  1 file changed, 20 insertions(+), 20 deletions(-)
>>>
> ...
>>
>> Reviewed-by: Neil Armstrong 
> 
> There is now a much simpler v6 of this patch.
> Care to take a look and ack/r-b?

I saw it too late, I reviewed the bridge patches, now
I'll have a look at the whole patchset.

Neil

> 
>   Sam
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 21/24] drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Neil Armstrong
On 26/07/2019 19:23, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index dbf35c7bc85e..61cc2354ef1b 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -134,8 +134,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
>  
>   drm_connector_helper_add(>connector,
>_con_helper_funcs);
> - ret = drm_connector_init(bridge->dev, >connector,
> -  _con_funcs, dvi->connector_type);
> + ret = drm_connector_init_with_ddc(bridge->dev, >connector,
> +   _con_funcs,
> +   dvi->connector_type,
> +   dvi->ddc);
>   if (ret) {
>   dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
>   return ret;
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Neil Armstrong
On 26/07/2019 19:23, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index d32885b906ae..8ef6539ae78a 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -111,8 +111,10 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>  
>   drm_connector_helper_add(>connector,
>_vga_con_helper_funcs);
> - ret = drm_connector_init(bridge->dev, >connector,
> -  _vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
> + ret = drm_connector_init_with_ddc(bridge->dev, >connector,
> +   _vga_con_funcs,
> +   DRM_MODE_CONNECTOR_VGA,
> +   vga->ddc);
>   if (ret) {
>   DRM_ERROR("Failed to initialize connector\n");
>   return ret;
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 20/23] drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Neil Armstrong
On 11/07/2019 13:26, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/bridge/ti-tfp410.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index dbf35c7bc85e..e55358f0a5ba 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -26,7 +26,6 @@ struct tfp410 {
>   unsigned intconnector_type;
>  
>   u32 bus_format;
> - struct i2c_adapter  *ddc;
>   struct gpio_desc*hpd;
>   int hpd_irq;
>   struct delayed_work hpd_work;
> @@ -55,10 +54,10 @@ static int tfp410_get_modes(struct drm_connector 
> *connector)
>   struct edid *edid;
>   int ret;
>  
> - if (!dvi->ddc)
> + if (!dvi->connector.ddc)
>   goto fallback;
>  
> - edid = drm_get_edid(connector, dvi->ddc);
> + edid = drm_get_edid(connector, dvi->connector.ddc);
>   if (!edid) {
>   DRM_INFO("EDID read failed. Fallback to standard modes\n");
>   goto fallback;
> @@ -98,8 +97,8 @@ tfp410_connector_detect(struct drm_connector *connector, 
> bool force)
>   return connector_status_disconnected;
>   }
>  
> - if (dvi->ddc) {
> - if (drm_probe_ddc(dvi->ddc))
> + if (dvi->connector.ddc) {
> + if (drm_probe_ddc(dvi->connector.ddc))
>   return connector_status_connected;
>   else
>   return connector_status_disconnected;
> @@ -297,8 +296,8 @@ static int tfp410_get_connector_properties(struct tfp410 
> *dvi)
>   if (!ddc_phandle)
>   goto fail;
>  
> - dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
> - if (dvi->ddc)
> + dvi->connector.ddc = of_get_i2c_adapter_by_node(ddc_phandle);
> + if (dvi->connector.ddc)
>   dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
>   else
>   ret = -EPROBE_DEFER;
> @@ -367,7 +366,7 @@ static int tfp410_init(struct device *dev, bool i2c)
>  
>   return 0;
>  fail:
> - i2c_put_adapter(dvi->ddc);
> + i2c_put_adapter(dvi->connector.ddc);
>   if (dvi->hpd)
>   gpiod_put(dvi->hpd);
>   return ret;
> @@ -382,8 +381,8 @@ static int tfp410_fini(struct device *dev)
>  
>   drm_bridge_remove(>bridge);
>  
> - if (dvi->ddc)
> - i2c_put_adapter(dvi->ddc);
> + if (dvi->connector.ddc)
> + i2c_put_adapter(dvi->connector.ddc);
>   if (dvi->hpd)
>   gpiod_put(dvi->hpd);
>  
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 19/23] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Neil Armstrong
ailed to read ddc node\n");
>   return ERR_PTR(-EPROBE_DEFER);
>   }
> @@ -2689,7 +2689,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   hdmi_init_clk_regenerator(hdmi);
>  
>   /* If DDC bus is not specified, try to register HDMI I2C bus */
> - if (!hdmi->ddc) {
> + if (!hdmi->connector.ddc) {
>   /* Look for (optional) stuff related to unwedging */
>   hdmi->pinctrl = devm_pinctrl_get(dev);
>   if (!IS_ERR(hdmi->pinctrl)) {
> @@ -2708,9 +2708,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   }
>   }
>  
> - hdmi->ddc = dw_hdmi_i2c_adapter(hdmi);
> - if (IS_ERR(hdmi->ddc))
> - hdmi->ddc = NULL;
> + hdmi->connector.ddc = dw_hdmi_i2c_adapter(hdmi);
> + if (IS_ERR(hdmi->connector.ddc))
> + hdmi->connector.ddc = NULL;
>   }
>  
>   hdmi->bridge.driver_private = hdmi;
> @@ -2776,7 +2776,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>  err_iahb:
>   if (hdmi->i2c) {
>   i2c_del_adapter(>i2c->adap);
> - hdmi->ddc = NULL;
> + hdmi->connector.ddc = NULL;
>   }
>  
>   if (hdmi->cec_notifier)
> @@ -2788,7 +2788,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>  err_isfr:
>   clk_disable_unprepare(hdmi->isfr_clk);
>  err_res:
> - i2c_put_adapter(hdmi->ddc);
> + i2c_put_adapter(hdmi->connector.ddc);
>  
>   return ERR_PTR(ret);
>  }
> @@ -2814,7 +2814,7 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
>   if (hdmi->i2c)
>   i2c_del_adapter(>i2c->adap);
>   else
> - i2c_put_adapter(hdmi->ddc);
> + i2c_put_adapter(hdmi->connector.ddc);
>  }
>  
>  /* 
> -
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 18/23] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory

2019-07-30 Thread Neil Armstrong
On 11/07/2019 13:26, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index d32885b906ae..b4cc3238400a 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -20,7 +20,6 @@ struct dumb_vga {
>   struct drm_bridge   bridge;
>   struct drm_connectorconnector;
>  
> - struct i2c_adapter  *ddc;
>   struct regulator*vdd;
>  };
>  
> @@ -42,10 +41,10 @@ static int dumb_vga_get_modes(struct drm_connector 
> *connector)
>   struct edid *edid;
>   int ret;
>  
> - if (IS_ERR(vga->ddc))
> + if (IS_ERR(vga->connector.ddc))
>   goto fallback;
>  
> - edid = drm_get_edid(connector, vga->ddc);
> + edid = drm_get_edid(connector, vga->connector.ddc);
>   if (!edid) {
>   DRM_INFO("EDID readout failed, falling back to standard 
> modes\n");
>   goto fallback;
> @@ -84,7 +83,7 @@ dumb_vga_connector_detect(struct drm_connector *connector, 
> bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + if (!IS_ERR(vga->connector.ddc) && drm_probe_ddc(vga->connector.ddc))
>   return connector_status_connected;
>  
>   return connector_status_unknown;
> @@ -190,14 +189,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>   dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>   }
>  
> - vga->ddc = dumb_vga_retrieve_ddc(>dev);
> - if (IS_ERR(vga->ddc)) {
> - if (PTR_ERR(vga->ddc) == -ENODEV) {
> + vga->connector.ddc = dumb_vga_retrieve_ddc(>dev);
> + if (IS_ERR(vga->connector.ddc)) {
> + if (PTR_ERR(vga->connector.ddc) == -ENODEV) {
>   dev_dbg(>dev,
>   "No i2c bus specified. Disabling EDID 
> readout\n");
>   } else {
>   dev_err(>dev, "Couldn't retrieve i2c bus\n");
> - return PTR_ERR(vga->ddc);
> + return PTR_ERR(vga->connector.ddc);
>   }
>   }
>  
> @@ -216,8 +215,8 @@ static int dumb_vga_remove(struct platform_device *pdev)
>  
>   drm_bridge_remove(>bridge);
>  
> - if (!IS_ERR(vga->ddc))
> - i2c_put_adapter(vga->ddc);
> + if (!IS_ERR(vga->connector.ddc))
> + i2c_put_adapter(vga->connector.ddc);
>  
>   return 0;
>  }
> 

Reviewed-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/59] drm/meson: Drop drm_gem_prime_export/import

2019-06-18 Thread Neil Armstrong
On 14/06/2019 22:35, Daniel Vetter wrote:
> They're the default.
> 
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.

Yep, adding this to my infinite TODO list

> 
> Signed-off-by: Daniel Vetter 
> Cc: Neil Armstrong 
> Cc: Kevin Hilman 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  drivers/gpu/drm/meson/meson_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index 140363f93575..37dca83d6eb1 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -101,8 +101,6 @@ static struct drm_driver meson_driver = {
>   /* PRIME Ops */
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import   = drm_gem_prime_import,
> - .gem_prime_export   = drm_gem_prime_export,
>   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>   .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
> 

Acked-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h

2019-01-15 Thread Neil Armstrong
|  2 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c|  2 +-
>  drivers/gpu/drm/cirrus/cirrus_drv.c   |  1 +
>  drivers/gpu/drm/cirrus/cirrus_mode.c  |  1 +
>  drivers/gpu/drm/drm_atomic_helper.c   |  1 -
>  drivers/gpu/drm/drm_dp_mst_topology.c |  2 +-
>  drivers/gpu/drm/drm_modeset_helper.c  |  2 +-
>  drivers/gpu/drm/drm_probe_helper.c|  2 +-
>  drivers/gpu/drm/drm_simple_kms_helper.c   |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
>  drivers/gpu/drm/exynos/exynos_dp.c|  3 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c   |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c |  2 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h|  1 +
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|  2 +-
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  2 +-
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 +-
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c  |  2 +-
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c  |  2 +-
>  .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  2 +-
>  .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c   |  2 +-
>  drivers/gpu/drm/i2c/ch7006_priv.h |  1 +
>  drivers/gpu/drm/i2c/sil164_drv.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/i915_debugfs.c   |  3 +-
>  drivers/gpu/drm/i915/i915_drv.c   |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c   |  2 +
>  drivers/gpu/drm/i915/i915_ioc32.c |  1 +
>  drivers/gpu/drm/i915/i915_irq.c   |  2 +
>  drivers/gpu/drm/i915/i915_pci.c   |  2 +
>  drivers/gpu/drm/i915/i915_trace.h |  2 +
>  drivers/gpu/drm/i915/intel_crt.c  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/intel_dp.c   |  2 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  3 +-
>  drivers/gpu/drm/i915/intel_fbc.c  |  2 +
>  drivers/gpu/drm/i915/intel_fbdev.c|  2 +
>  drivers/gpu/drm/i915/intel_lpe_audio.c|  1 +
>  drivers/gpu/drm/i915/intel_overlay.c  |  2 +
>  drivers/gpu/drm/imx/dw_hdmi-imx.c |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c|  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c |  2 +-
>  drivers/gpu/drm/imx/imx-tve.c |  2 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c  |  2 +-
>  drivers/gpu/drm/imx/parallel-display.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_dpi.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c |  2 +-
>  drivers/gpu/drm/mediatek/mtk_dsi.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/meson/meson_crtc.c|  2 +-
>  drivers/gpu/drm/meson/meson_drv.c |  2 +-
>  drivers/gpu/drm/meson/meson_dw_hdmi.c |  2 +-
>  drivers/gpu/drm/meson/meson_venc_cvbs.c   |  2 +-

For meson:

Acked-by: Neil Armstrong 

>  drivers/gpu/drm/mgag200/mgag200_mode.c|  1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |  2 +-
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  2 +-
>  .../gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c  |  2 +-
>  .../gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c  |  2 +-
>  .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c |  2 +-
>  .../gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c  |  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c  |  2 +-
>  drivers/gpu/drm/msm/msm_drv.h |  2 +-
>  drivers/gpu/drm/msm/msm_fb.c  |  2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c|  2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c |  2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_out.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |  1 +
>  drivers/gpu/drm/nouveau/di

Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h

2018-12-10 Thread Neil Armstrong
bs.c
> index f7945bae3b4a..64de3a7026d0 100644
> --- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
> +++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
> @@ -27,7 +27,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include "meson_venc_cvbs.h"

[...]
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 0ee9a96b70da..a6d520d5b6ca 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -58,20 +58,4 @@ int drm_helper_connector_dpms(struct drm_connector 
> *connector, int mode);
>  void drm_helper_resume_force_mode(struct drm_device *dev);
>  int drm_helper_force_disable_all(struct drm_device *dev);
>  
> -/* drm_probe_helper.c */
> -int drm_helper_probe_single_connector_modes(struct drm_connector
> - *connector, uint32_t maxX,
> - uint32_t maxY);
> -int drm_helper_probe_detect(struct drm_connector *connector,
> - struct drm_modeset_acquire_ctx *ctx,
> - bool force);
> -void drm_kms_helper_poll_init(struct drm_device *dev);
> -void drm_kms_helper_poll_fini(struct drm_device *dev);
> -bool drm_helper_hpd_irq_event(struct drm_device *dev);
> -void drm_kms_helper_hotplug_event(struct drm_device *dev);
> -
> -void drm_kms_helper_poll_disable(struct drm_device *dev);
> -void drm_kms_helper_poll_enable(struct drm_device *dev);
> -bool drm_kms_helper_is_poll_worker(void);
> -
>  #endif
> diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
> new file mode 100644
> index ..96c060c16a1e
> --- /dev/null
> +++ b/include/drm/drm_probe_helper.h
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright © 2006 Keith Packard
> + * Copyright © 2007-2008 Dave Airlie
> + * Copyright © 2007-2008 Intel Corporation
> + *   Jesse Barnes 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __DRM_PROBE_HELPER_H__
> +#define __DRM_PROBE_HELPER_H__
> +
> +#include 
> +
> +struct drm_connector;
> +struct drm_device;
> +struct drm_modeset_acquire_ctx;
> +
> +int drm_helper_probe_single_connector_modes(struct drm_connector
> + *connector, uint32_t maxX,
> + uint32_t maxY);
> +int drm_helper_probe_detect(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool force);
> +void drm_kms_helper_poll_init(struct drm_device *dev);
> +void drm_kms_helper_poll_fini(struct drm_device *dev);
> +bool drm_helper_hpd_irq_event(struct drm_device *dev);
> +void drm_kms_helper_hotplug_event(struct drm_device *dev);
> +
> +void drm_kms_helper_poll_disable(struct drm_device *dev);
> +void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
> +
> +#endif
> 

Acked-by: Neil Armstrong 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [GIT PULL] Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window

2018-07-16 Thread Neil Armstrong
Hi Dave, Rodrigo.

On 13/07/2018 09:46, Lee Jones wrote:
> Enjoy!
> 
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> ib-mfd-i915-media-platform-v4.19
> 
> for you to fetch changes up to cd70de2d356ee692477276bd5d6bc88c71a48733:
> 
>   media: platform: Add ChromeOS EC CEC driver (2018-07-13 08:44:46 +0100)
> 
> 
> Immutable branch between MFD and DRM/i915, Media and Platform due for the 
> v4.19 merge window


This PR is here to solve a complex interdependency over this patchset,
Hans agreed all the media patches go to the MFD tree and Rodrigo acked the i915
patch so it could be applied to another tree,
but who is suposed to take this PR to the DRM tree ?

Neil

> 
> --------
> 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 |  97 +++
>  include/media/cec-notifier.h |  27 +-
>  14 files changed, 578 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
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v8 0/6] Add ChromeOS EC CEC Support

2018-07-12 Thread Neil Armstrong
Hi Lee,

On 12/07/2018 14:26, Lee Jones wrote:
> On Wed, 04 Jul 2018, 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.
>>
>> Feel free to comment this patchset !
>>
>> Changes since v7:
>> - rebased on v4.18-rc1
>> - Fixed whitespace issues on patch 3
>> - Added Lee's tags
>>
>> 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 |  97 +++
>>  include/media/cec-notifier.h |  27 +-
>>  14 files changed, 578 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
> 
> How would you like to handle this set?
> 

Hans proposed you take all the patches throught mfd,
then drm-intel could merge your immutable branch to avoid any conflicts.

Rodrigo Vivi gave an ack to merge it through other trees on the v6 patchset.

Hans, should the media tree also merge the branch ?

Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-07-04 Thread 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 
Tested-by: Enric Balletbo i Serra 
Reviewed-by: Hans Verkuil 
Acked-for-MFD-by: Lee Jones 
---
 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 c4f0caa..584e04e 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,
 };
@@ -2847,6 +2855,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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v8 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

2018-07-04 Thread 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 
Reviewed-by: Enric Balletbo i Serra 
Acked-by: Hans Verkuil 
Acked-for-MFD-by: Lee Jones 
---
 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 306e1fd..1e2049f 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -377,6 +377,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" }
 };
@@ -419,6 +423,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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v8 6/6] media: platform: Add ChromeOS EC CEC driver

2018-07-04 Thread 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 
Reviewed-by: Enric Balletbo i Serra 
Reviewed-by: Hans Verkuil 
---
 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 2728376..e4fc59b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -533,6 +533,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 04bc150..890f919 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -93,3 +93,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 000..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 000..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 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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_devic

[Intel-gfx] [PATCH v8 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-07-04 Thread 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 
Reviewed-by: Hans Verkuil 
Reviewed-by: Ville Syrjälä 
Acked-by: Rodrigo Vivi 
---
 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 2ef3161..1f176a71 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 "";
+   }
+}
+
 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 0361130..cfbeee1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __wait_for - magic wait macro
@@ -1017,6 +1018,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 ee929f3..c21b7dd 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);
@@ -2350,6 +2358,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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-07-04 Thread 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 
Reviewed-by: Hans Verkuil 
---
 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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

___

[Intel-gfx] [PATCH v8 0/6] Add ChromeOS EC CEC Support

2018-07-04 Thread 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 v7:
- rebased on v4.18-rc1
- Fixed whitespace issues on patch 3
- Added Lee's tags

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 |  97 +++
 include/media/cec-notifier.h |  27 +-
 14 files changed, 578 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-07-04 Thread 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 
Signed-off-by: Neil Armstrong 
Tested-by: Enric Balletbo i Serra 
Acked-by: Hans Verkuil 
---
 drivers/platform/chrome/cros_ec_proto.c | 40 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 16 +
 3 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index 8350ca2..398393a 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -506,10 +506,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(_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 *)
+   static int cmd_version = 1;
int ret;
 
if (ec_dev->suspended) {
@@ -517,18 +538,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(_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 32421df..20949dd 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..c4f0caa 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2093,12 +2093,28 @@ union ec_response_get_next_data {
uint32_t   sysrq;
 } __packed;
 
+union ec_response_get_next_data_v1 {
+   uint8_t key_matrix[16];
+   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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-07-04 Thread 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 
>> Reviewed-by: Enric Balletbo i Serra 
>> Acked-by: Hans Verkuil 
>> ---
>>  drivers/mfd/cros_ec_dev.c | 16 
>>  1 file changed, 16 insertions(+)
> 
> For my own reference:
>   Acked-for-MFD-by: Lee Jones 
> 

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

Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-07-03 Thread 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 
>>>> Signed-off-by: Neil Armstrong 
>>>> Tested-by: Enric Balletbo i Serra 
>>>> ---
>>>>  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(_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 *)
>>>> +  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(_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;
>>>>  };
>>>

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

2018-06-18 Thread 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 
>> Signed-off-by: Neil Armstrong 
>> Tested-by: Enric Balletbo i Serra 
>> ---
>>  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(_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 *)
>> +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(_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_tcec_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_BUTTON0
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-11 Thread 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-08 Thread 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/i

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

2018-06-01 Thread 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 
Reviewed-by: Enric Balletbo i Serra 
Reviewed-by: Hans Verkuil 
---
 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 000..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 000..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 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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_devic

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

2018-06-01 Thread 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 
Reviewed-by: Enric Balletbo i Serra 
Acked-by: Hans Verkuil 
---
 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-01 Thread 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 
Tested-by: Enric Balletbo i Serra 
Reviewed-by: Hans Verkuil 
---
 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-01 Thread 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-01 Thread 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 
Reviewed-by: Hans Verkuil 
Reviewed-by: Ville Syrjälä 
Acked-by: Rodrigo Vivi 
---
 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 "";
+   }
+}
+
 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 
 #include 
 #include 
+#include 
 
 /**
  * __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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-01 Thread 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 
Signed-off-by: Neil Armstrong 
Tested-by: Enric Balletbo i Serra 
---
 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(_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 *)
+   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(_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_tcec_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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-06-01 Thread 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 
Reviewed-by: Hans Verkuil 
---
 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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

___

Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-31 Thread Neil Armstrong
On 31/05/2018 01:26, Rodrigo Vivi wrote:
> On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
>> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>>> 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 
>>> Reviewed-by: Hans Verkuil 
>>> ---
>>>  drivers/gpu/drm/i915/Kconfig |  1 +
>>>  drivers/gpu/drm/i915/intel_display.h | 20 
>>>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>>  drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>>  4 files changed, 36 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..c68d1c8 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.h
>>> +++ b/drivers/gpu/drm/i915/intel_display.h
>>> @@ -126,6 +126,26 @@ enum port {
>>>  
>>>  #define port_name(p) ((p) + 'A')
>>>  
>>> +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 "";
>>> +   }
>>> +}
>>
>> Could use a comment to make it clear that this identifier is
>> expected to remain stable since it's referenced from other drivers.
>>
>>> +
>>>  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..b50e51b 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -39,6 +39,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  /**
>>>   * __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 *notifier;
>>
>> "notifier" seems a bit too generic a name. "cec_notifier" would be
>> better.
>>
>> Apart from that this seems OK to me
>> Reviewed-by: Ville Syrjälä 
> 
> It seems that you will need to push this to other trees right?
> Feel free to use:
> 
> Acked-by: Rodrigo Vivi 

You are right, it will useful, thanks !

Neil

> 
>>
>>>  };
>>>  
>>>  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..d522b5b 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->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-&g

Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-31 Thread Neil Armstrong
On 30/05/2018 17:29, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
>> 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 
>> Reviewed-by: Hans Verkuil 
>> ---
>>  drivers/gpu/drm/i915/Kconfig |  1 +
>>  drivers/gpu/drm/i915/intel_display.h | 20 
>>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>  drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>  4 files changed, 36 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..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>  
>>  #define port_name(p) ((p) + 'A')
>>  
>> +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 "";
>> +}
>> +}
> 
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
> 
>> +
>>  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..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /**
>>   * __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 *notifier;
> 
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.

OK

> 
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä 

Thanks for the review !

Neil

> 
>>  };
>>  
>>  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..d522b5b 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->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->notifier);
>> +
>>  return status;
>>  }
&

[Intel-gfx] [PATCH v6 6/6] media: platform: Add ChromeOS EC CEC driver

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
Reviewed-by: Hans Verkuil <hans.verk...@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 000..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 000..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 <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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_

[Intel-gfx] [PATCH v6 0/6] Add ChromeOS EC CEC Support

2018-05-24 Thread 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 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 |  20 ++
 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, 577 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v5 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-05-24 Thread 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 <narmstr...@baylibre.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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

_

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

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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 physi

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

2018-05-24 Thread 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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@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(_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 *)
+   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(_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_tcec_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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/intel_display.h | 20 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 13 +
 4 files changed, 36 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..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
 
 #define port_name(p) ((p) + 'A')
 
+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 "";
+   }
+}
+
 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..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __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 *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..d522b5b 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->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->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)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->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->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-05-24 Thread Neil Armstrong
On 24/05/2018 11:11, Hans Verkuil wrote:
> On 24/05/18 10:54, 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 <narmstr...@baylibre.com>
>> Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
>> ---
>>  include/linux/mfd/cros_ec_commands.h | 85 
>> 
>>  1 file changed, 85 insertions(+)
>>
>> diff --git a/include/linux/mfd/cros_ec_commands.h 
>> b/include/linux/mfd/cros_ec_commands.h
>> index cc0768e..ea9646f 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_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,83 @@ struct ec_params_reboot_ec {
>>  
>>  
>> /*/
>>  /*
>> + * HDMI CEC commands
>> + *
>> + * These commands are for sending and receiving message via HDMI CEC
>> + */
>> +#define MAX_CEC_MSG_LEN 16
> 
> Can you rename this to EC_MAX_CEC_MSG_LEN? It is way too similar to the
> CEC_MAX_MSG_LEN defined in cec.h. Since this is a property of the EC hw/fw
> it makes sense to prefix it accordingly.

Yes, it will make sense.

> 
>> +
>> +/* 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[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
>> + * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable 
>> CEC
>> + *  or 1 to enable CEC functionnality
>> + * @address: 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 */
>> +union {
>> +uint8_t enable;
>> +uint8_t address;
>> +};
>> +} __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
>> + * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
>> + *  disabled or 1 if CEC functionnality is enabled
>> + * @address: 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 {
>> +union {
>> +uint8_t enable;
>> +uint8_t address;
>> +};
>> +} __packed;
>> +
>> +/* CEC parameters command */
>> +enum cec_command {
> 
> Same here: shouldn't all of this be prefixed with ec_ or EC_?

Exact, I will prefix them.

Thanks,
Neil

> 
> Regards,
> 
>   Hans
> 
>> +/* 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 {
>> +EC_MKBP_CEC_SEND_OK = BIT(0),
>> +EC_MKBP_CEC_SEND_FAILED = BIT(1),
>> +};
>> +
>> +/*/
>> +/*
>>   * Special commands
>>   *
>>   * These do not follow the normal rules for commands.  See each command for
>>
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.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 000..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 000..7f897a2
--- /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 <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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 *_n

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

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.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 functionnality, 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 functionnality 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v5 0/6] Add ChromeOS EC CEC Support

2018-05-24 Thread 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 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 Reviwed-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 |  20 ++
 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 | 104 +++
 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-05-24 Thread 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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@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(_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 *)
+   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(_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_tcec_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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v5 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/intel_display.h | 20 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 13 +
 4 files changed, 36 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..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
 
 #define port_name(p) ((p) + 'A')
 
+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 "";
+   }
+}
+
 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..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __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 *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..d522b5b 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->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->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)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->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->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2018-05-24 Thread 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 <narmstr...@baylibre.com>
Tested-by: Enric Balletbo i Serra <enric.balle...@collabora.com>
---
 include/linux/mfd/cros_ec_commands.h | 85 
 1 file changed, 85 insertions(+)

diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index cc0768e..ea9646f 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_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,83 @@ struct ec_params_reboot_ec {
 
 /*/
 /*
+ * HDMI CEC commands
+ *
+ * These commands are for sending and receiving message via HDMI CEC
+ */
+#define 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[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
+ * @enable: in case cmd is CEC_CMD_ENABLE, this field can be 0 to disable CEC
+ * or 1 to enable CEC functionnality
+ * @address: 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 */
+   union {
+   uint8_t enable;
+   uint8_t address;
+   };
+} __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
+ * @enable: in case cmd was CEC_CMD_ENABLE, this field will 0 if CEC is
+ * disabled or 1 if CEC functionnality is enabled
+ * @address: 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 {
+   union {
+   uint8_t enable;
+   uint8_t address;
+   };
+} __packed;
+
+/* CEC parameters command */
+enum 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 {
+   EC_MKBP_CEC_SEND_OK = BIT(0),
+   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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-24 Thread Neil Armstrong
Hi Benson,

On 24/05/2018 07:47, Benson Leung wrote:
> Hi Neil, Hi Stefan,
> 
> On Fri, May 18, 2018 at 03:05:02PM +0200, Neil Armstrong wrote:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>> 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
> 
> It looks like this change squashes together this chromeos-4.4 CL
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1061879
> and some other new changes to add cec to cros_ec_commands.
> 
> Could you separate the two? One patch that's as close to Stefan's
> which introduces the 16 byte mkbp, and a second one that
> adds the HDMI CEC commands? 

OK, will split.

Neil

> 
> Thanks,
> Benson
>> ---
>>  drivers/platform/chrome/cros_ec_proto.c | 40 +
>>  include/linux/mfd/cros_ec.h |  2 +-
>>  include/linux/mfd/cros_ec_commands.h| 80 
>> +
>>  3 files changed, 112 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(_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 *)
>> +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(_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..16c3a2b 100644
>> --- a/include/

[Intel-gfx] [PATCH v4 0/5] Add ChromeOS EC CEC Support

2018-05-21 Thread 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 v3 (incorrectly reported as v2):
 - Renamed "Chrome OS" to "ChromeOS"
 - Updated cros_ec_commands.h new structs definitions to kernel doc format
 - Added Reviwed-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 (5):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  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 |  20 ++
 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 | 103 +++
 include/media/cec-notifier.h |  27 +-
 14 files changed, 580 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v4 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-21 Thread Neil Armstrong
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
 drivers/platform/chrome/cros_ec_proto.c |  40 ++---
 include/linux/mfd/cros_ec.h |   2 +-
 include/linux/mfd/cros_ec_commands.h| 103 
 3 files changed, 135 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(_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 *)
+   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(_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..9b8bc4a 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_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,
 };
@@ -2093,12 +2101,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_tcec_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 

[Intel-gfx] [PATCH v4 1/5] media: cec-notifier: Get notifier by device and connector name

2018-05-21 Thread 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 <narmstr...@baylibre.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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

_

[Intel-gfx] [PATCH v4 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-21 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v4 5/5] media: platform: Add ChromeOS EC CEC driver

2018-05-21 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.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 000..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 000..7f897a2
--- /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 <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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 *_n

[Intel-gfx] [PATCH v4 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-21 Thread 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 <narmstr...@baylibre.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/intel_display.h | 20 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 13 +
 4 files changed, 36 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..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
 
 #define port_name(p) ((p) + 'A')
 
+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 "";
+   }
+}
+
 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..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __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 *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..d522b5b 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->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->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)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->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->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support

2018-05-21 Thread Neil Armstrong
On 18/05/2018 16:04, Enric Balletbo Serra wrote:
> Hi Neil,
> 
> 2018-05-18 15:04 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>:
>> 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 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
>>
> 
> Just because I got confused when I saw two v2 in my inbox. This is v3, right?

Yes, sorry it's v3... next will be v4.

> 
>> 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 (5):
>>   media: cec-notifier: Get notifier by device and connector name
>>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>>   mfd: cros-ec: Introduce CEC commands and events definitions.
>>   mfd: cros_ec_dev: Add CEC sub-device registration
>>   media: platform: Add Chrome OS EC CEC driver
>>
>>  drivers/gpu/drm/i915/Kconfig |   1 +
>>  drivers/gpu/drm/i915/intel_display.h |  20 ++
>>  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 |  80 ++
>>  include/media/cec-notifier.h |  27 +-
>>  14 files changed, 557 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
>>

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

2018-05-21 Thread Neil Armstrong
Hi Enric,

On 18/05/2018 17:02, Enric Balletbo Serra wrote:
> Hi Neil,
> 
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>:
>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> 
> A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
> Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in
> the kernel many other ways to refer to the ChromeOS EC, but to
> standardize a little bit, could you replace all occurrences s/Chrome
> OS/ChromeOS/. Thanks.

Ok, I'll do a cleanup.

> 
>> 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 <narmstr...@baylibre.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..e55a8ed2 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 "Chrome OS EC CEC driver"
> 
> here
> 
>> +   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
>> + Chrome OS Embedded Controller's CEC.
> 
> here
> 
>> + 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 000..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 000..7e1e275
>> --- /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 Chrome OS Embedded Controller
> 
> and here
> 
>> + *
>> + * Copyright (c) 2018 BayLibre, SAS
>> + * Author: Neil Armstrong <narmstr...@baylibre.com>
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#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 {
>

Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-21 Thread Neil Armstrong
Hi Enric,

On 18/05/2018 18:19, Enric Balletbo Serra wrote:
> Hi Neil,
> 
> 2018-05-18 15:05 GMT+02:00 Neil Armstrong <narmstr...@baylibre.com>:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>> 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>>  drivers/platform/chrome/cros_ec_proto.c | 40 +
>>  include/linux/mfd/cros_ec.h |  2 +-
>>  include/linux/mfd/cros_ec_commands.h| 80 
>> +
>>  3 files changed, 112 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(_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 *)
>> +   static int cmd_version = 1;
> 
> Personal opinion, but I don't like this static here, and also I don't
> think this is scalable. Could we ask for the command version?

I don't have an opinion, I only followed how it was implemented on the
chromeos kernel and adapted to mainline. If you have a better way, I'll use it !

> 
>> 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(_dev->event_data, msg->data,
>> -  sizeof(ec_dev->event_data));
>> +   /* Fallback to version 0 for future send attempts */
>> +   cmd_version = 0;
>> }
>>
> 
> So we always do a failed transfer on all these EC devices that does
> not support CEC. I am wondering if wouldn't be better pass the command
> version to the cros_ec_get_next_event function. The driver should know
> which version to use, just a random idea.

No, the driver cannot know the command version, this depends on the FW version
and the platform. AFAIK this must be discovered.

> 
>> +   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_noti

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-21 Thread Neil Armstrong
Hi Ville,

On 18/05/2018 15:24, Ville Syrjälä wrote:
> On Fri, May 18, 2018 at 03:05:01PM +0200, Neil Armstrong wrote:
>> 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 <narmstr...@baylibre.com>
>> ---
>>  drivers/gpu/drm/i915/Kconfig |  1 +
>>  drivers/gpu/drm/i915/intel_display.h | 20 
>>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>  drivers/gpu/drm/i915/intel_hdmi.c| 13 +
>>  4 files changed, 36 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..c68d1c8 100644
>> --- a/drivers/gpu/drm/i915/intel_display.h
>> +++ b/drivers/gpu/drm/i915/intel_display.h
>> @@ -126,6 +126,26 @@ enum port {
>>  
>>  #define port_name(p) ((p) + 'A')
>>  
>> +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 "";
>> +}
>> +}
> 
> I don't think we need this in the header. A static function will do.

I just followed how other functions were declared, in the same way.

> And I was actually thinking something a bit fancier like:
> snprintf("%s/port-%s", dev_name(dev), port_id(port));
> 
> Oh, I see you already pass the device in so I guess we don't need
> that in the port id?

Indeed, my bad I forgot to answer your last question, we already pass a struct
device which provides the device bus, name and id, so it's unneeded here.

> 
>> +
>>  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..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /**
>>   * __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 *notifier;
> 
> I was wondering if we need any ifdefs around this stuff, but I guess not
> since it's just a pointer and all the functions seem to have empty
> static inlines for the CEC=n case.
> 
>>  };
>>  
>>  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..d522b5b 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->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 @

Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

2018-05-21 Thread Neil Armstrong
Hi Sean,

On 18/05/2018 17:48, Sean Paul wrote:
> On Fri, May 18, 2018 at 03:05:00PM +0200, Neil Armstrong wrote:
>> 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 <narmstr...@baylibre.com>
> 
> Hi Neil,
> Thanks for posting these!
> 
>> ---
>>  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(_notifiers_lock);
>>  list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>>  kref_get(>kref);
>>  mutex_unlock(_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(>lock);
>>  kref_init(>kref);
>> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>>  mutex_unlock(_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(>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
> 
> Probably best to use "name" instead of connector, since it doesn't necessarily
> _have_ to be a connector name. So, cec_notifier_get_by_name(dev, name)

I don't have a stong opinion, but since the CEC is tied to a connector, it 
should
mention connector, maybe conn_name ?

> 
>>   *
>>   * 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

[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

2018-05-18 Thread 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 <narmstr...@baylibre.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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

_

[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

2018-05-18 Thread Neil Armstrong
The Chrome OS 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 <narmstr...@baylibre.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..e55a8ed2 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 "Chrome OS 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
+ Chrome OS 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 000..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 000..7e1e275
--- /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 Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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_dev

[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-18 Thread 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 <narmstr...@baylibre.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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-18 Thread 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 <narmstr...@baylibre.com>
---
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/intel_display.h | 20 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 13 +
 4 files changed, 36 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..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
 
 #define port_name(p) ((p) + 'A')
 
+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 "";
+   }
+}
+
 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..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __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 *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..d522b5b 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->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->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)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->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->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-18 Thread Neil Armstrong
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
 drivers/platform/chrome/cros_ec_proto.c | 40 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 112 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(_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 *)
+   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(_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..16c3a2b 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_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,
 };
@@ -2093,12 +2101,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_tcec_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 

[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support

2018-05-18 Thread 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 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 (5):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Introduce CEC commands and events definitions.
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: platform: Add Chrome OS EC CEC driver

 drivers/gpu/drm/i915/Kconfig |   1 +
 drivers/gpu/drm/i915/intel_display.h |  20 ++
 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 |  80 ++
 include/media/cec-notifier.h |  27 +-
 14 files changed, 557 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-16 Thread Neil Armstrong
Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
>>>> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>>>>> 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 <narmstr...@baylibre.com>
>>>>> ---
>>>>>  drivers/gpu/drm/i915/Kconfig  |  1 +
>>>>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>>>>>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>>>>>  3 files changed, 15 insertions(+)
>>>>>
>>>
>>> [..]
>>>
>>>>>  }
>>>>>  
>>>>> @@ -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)->notifier)
>>>>> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>>>>>   kfree(to_intel_connector(connector)->detect_edid);
>>>>>   drm_connector_cleanup(connector);
>>>>>   kfree(connector);
>>>>> @@ -2358,6 +2366,10 @@ 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->notifier = cec_notifier_get_conn(dev->dev, connector->name);
>>>>
>>>> What are we doing with the connector name here? Those are not actually
>>>> guaranteed to be stable, and any change in the connector probe order
>>>> may cause the name to change.
>>>
>>> The i915 driver can expose multiple HDMI connectors, but each connected will
>>> have a different EDID and CEC physical address, so we will need a different 
>>> notifier
>>> for each connector.
>>>
>>> The connector name is DRM dependent, but user-space actually uses this name 
>>> for
>>> operations, so I supposed it was kind of stable.
>>>
>>> Anyway, is there another stable id/name/whatever that can be used to make a 
>>> name to
>>> distinguish the HDMI connectors ?
>>
>> Would "HDMI %c", port_name(port) be OK to use ?
> 
> Yeah, something like seems like a reasonable approach. That does mean
> we have to be a little careful with changing enum port or port_name()
> in the future, but I guess we could just add a small function to
> generated the name/id specifically for this thing.
> 
> We're also going to have to think what to do with enum port and
> port_name() on ICL+ though. There we won't just have A-F but also
> TC1-TC. Hmm. Looks like what we have for those ports in our
> codebase ATM is a bit wonky since we haven't even changed
> port_name() to give us the TC type names.
> 
> Also we might not want "HDMI" in the identifier since the physical
> port is not HDMI specific. There are different things we could call
> these but I think we could just go with a generic "Port A-F" and
> "Port TC1-TC" approach. I think something like that should work
> fine for current and upcoming hardware. And in theory that could
> then be used for other things as well which need a stable
> identifier.
> 
> Oh, and now I recall that input subsystem at least has some kind
> of "physical path" property on devices. So I guess what we're
> dicussing is a somewhat similar idea. I think input drivers
> generally include the pci/usb/etc. device in the path as well.
> Even though we currently only ever have the one pci device it
> would seem like decent idea to include that information in our
> identifiers as well. Or what do you think?
> 

Thanks for the clarifications !

Having a "Port " will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
enum port port)
{
char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

if (id)
return NULL;

snprintf("Port %c", port_name(port));

return id;
}

and use the result of this for the cec_notifier connector name ?

Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-16 Thread Neil Armstrong
Hi Hans,

On 15/05/2018 17:28, Hans Verkuil wrote:
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>> 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 <sadolfs...@chromium.org>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>>  drivers/platform/chrome/cros_ec_proto.c | 42 +
>>  include/linux/mfd/cros_ec.h |  2 +-
>>  include/linux/mfd/cros_ec_commands.h| 80 
>> +
>>  3 files changed, 114 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
>> b/drivers/platform/chrome/cros_ec_proto.c
>> index e7bbdf9..ba47f79 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -504,29 +504,53 @@ 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(_dev->event_data, msg->data, 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 *)
>> +static int cmd_version = 1;
>>  int ret;
>>  
>> +BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
> 
> Use the define instead of hardcoding 16. I'm not really sure why you need 
> this.
> If cec_message uses the right define for the array size (see my comment 
> below),
> then this really can't go wrong, can it?

This is taken from the chrome kernelk, to be sure the size is ok, but yes it 
should be 16, I'll see
if I can drop this.

> 
>> +
>>  if (ec_dev->suspended) {
>>  dev_dbg(ec_dev->dev, "Device suspended.\n");
>>  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(ec_dev->event_data));
>> +if (ret != EC_RES_INVALID_VERSION)
>> +return ret;
>>  
>> -ret = cros_ec_cmd_xfer(ec_dev, msg);
>> -if (ret > 0) {
>> -ec_dev->event_size = ret - 1;
>> -memcpy(_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 2d4e23c..f3415eb 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..18df466 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 {
>> 

Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-16 Thread Neil Armstrong
Hi Enric,

On 15/05/2018 18:40, Enric Balletbo Serra wrote:
> Hi Neil,
> 
> I suspect that this patch will conflict with some patches that will be
> queued for 4.18 that also introduces new devices, well, for now I
> don't see these merged in the Lee's tree.

Indeed, I found your patches, I'll rebase this one when Lee pushes them in his 
tree.

> 
> Based on some reviews I got when I send a patch to this file ...
> 
> 2018-05-15 17:29 GMT+02:00 Hans Verkuil <hverk...@xs4all.nl>:
>> On 05/15/2018 04:42 PM, 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 <narmstr...@baylibre.com>
>>
>> For what it is worth (not an MFD expert):
>>
>> Acked-by: Hans Verkuil <hans.verk...@cisco.com>
>>
>> Thanks!
>>
>> Hans
>>
>>> ---
>>>  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 eafd06f..57064ec 100644
>>> --- a/drivers/mfd/cros_ec_dev.c
>>> +++ b/drivers/mfd/cros_ec_dev.c
>>> @@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct 
>>> cros_ec_dev *ec)
>>>   kfree(msg);
>>>  }
>>>
>>> +static void cros_ec_cec_register(struct cros_ec_dev *ec)
>>> +{
>>> + int ret;
>>> + struct mfd_cell cec_cell = {
>>> + .name = "cros-ec-cec",
>>> + };
>>> +
>>> + ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
>>> + if (ret)
>>> + dev_err(ec->dev, "failed to add EC CEC\n");
>>> +}
>>> +
> 
> Do not create a single function to only call mfd_add_devices, instead
> do the following on top:
> 
> static const struct mfd_cell cros_ec_cec_cells[] = {
> { .name = "cros-ec-cec" }
> };

OK

> 
> 
>>>  static int ec_device_probe(struct platform_device *pdev)
>>>  {
>>>   int retval = -ENOMEM;
>>> @@ -422,6 +434,10 @@ 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 handles CEC. */
>>> + if (cros_ec_check_features(ec, EC_FEATURE_CEC))
>>> + cros_ec_cec_register(ec);
>>> +
> 
> and use PLATFORM_DEVID_AUTO and the ARRAY_SIZE macro, something like this.
> 
> /* Check whether this EC instance handles CEC */
> 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);
> }

Ok, like the RTC registration.

Thanks,
Neil

> 
> Best regards,
>   Enric
> 
>>>   /* Take control of the lightbar from the EC. */
>>>   lb_manual_suspend_ctrl(ec, 1);
>>>
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-16 Thread Neil Armstrong
On 16/05/2018 09:31, Neil Armstrong wrote:
> Hi Ville,
> 
> On 15/05/2018 17:35, Ville Syrjälä wrote:
>> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>>> 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 <narmstr...@baylibre.com>
>>> ---
>>>  drivers/gpu/drm/i915/Kconfig  |  1 +
>>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>>>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>>>  3 files changed, 15 insertions(+)
>>>
> 
> [..]
> 
>>>  }
>>>  
>>> @@ -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)->notifier)
>>> +   cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>>> kfree(to_intel_connector(connector)->detect_edid);
>>> drm_connector_cleanup(connector);
>>> kfree(connector);
>>> @@ -2358,6 +2366,10 @@ 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->notifier = cec_notifier_get_conn(dev->dev, connector->name);
>>
>> What are we doing with the connector name here? Those are not actually
>> guaranteed to be stable, and any change in the connector probe order
>> may cause the name to change.
> 
> The i915 driver can expose multiple HDMI connectors, but each connected will
> have a different EDID and CEC physical address, so we will need a different 
> notifier
> for each connector.
> 
> The connector name is DRM dependent, but user-space actually uses this name 
> for
> operations, so I supposed it was kind of stable.
> 
> Anyway, is there another stable id/name/whatever that can be used to make a 
> name to
> distinguish the HDMI connectors ?

Would "HDMI %c", port_name(port) be OK to use ?

Neil

> 
> Neil
> 
>>
>>> +   if (!intel_hdmi->notifier)
>>> +   DRM_DEBUG_KMS("CEC notifier get failed\n");
>>>  }
>>>  
>>>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
>>> -- 
>>> 2.7.4
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-16 Thread Neil Armstrong
Hi Ville,

On 15/05/2018 17:35, Ville Syrjälä wrote:
> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>> 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 <narmstr...@baylibre.com>
>> ---
>>  drivers/gpu/drm/i915/Kconfig  |  1 +
>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>>  3 files changed, 15 insertions(+)
>>

[..]

>>  }
>>  
>> @@ -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)->notifier)
>> +cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>>  kfree(to_intel_connector(connector)->detect_edid);
>>  drm_connector_cleanup(connector);
>>  kfree(connector);
>> @@ -2358,6 +2366,10 @@ 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->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> 
> What are we doing with the connector name here? Those are not actually
> guaranteed to be stable, and any change in the connector probe order
> may cause the name to change.

The i915 driver can expose multiple HDMI connectors, but each connected will
have a different EDID and CEC physical address, so we will need a different 
notifier
for each connector.

The connector name is DRM dependent, but user-space actually uses this name for
operations, so I supposed it was kind of stable.

Anyway, is there another stable id/name/whatever that can be used to make a 
name to
distinguish the HDMI connectors ?

Neil

> 
>> +if (!intel_hdmi->notifier)
>> +DRM_DEBUG_KMS("CEC notifier get failed\n");
>>  }
>>  
>>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
>> -- 
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

2018-05-15 Thread Neil Armstrong
On 15/05/2018 17:22, Hans Verkuil wrote:
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> 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.
> 
> The patch looks good, but I'm curious about this paragraph above.
> 
> Was this tested with devices with more than one HDMI output? Or only on
> laptops with a single physical HDMI output? If there are two or more
> outputs then I guess it is the HW designer that decides with output gets
> CEC support?

The driver exposes 2 HDMI connectors (I suspect one is connected to the USB-C 
alt mode mux along the DP port),
and only one connected has the CEC line connected to the Embedded Controller.

Neil

> 
> Regards,
> 
>   Hans
> 
>>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.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(_notifiers_lock);
>>  list_for_each_entry(n, _notifiers, head) {
>> -if (n->dev == dev) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>>  kref_get(>kref);
>>  mutex_unlock(_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(>lock);
>>  kref_init(>kref);
>> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>>  mutex_unlock(_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(>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_g

[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

2018-05-15 Thread Neil Armstrong
The Chrome OS 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 <narmstr...@baylibre.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 | 335 +++
 4 files changed, 349 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..e55a8ed2 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 "Chrome OS 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
+ Chrome OS 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 000..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 000..aed3368
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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, _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_dev

[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-15 Thread 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 <narmstr...@baylibre.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 eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+   int ret;
+   struct mfd_cell cec_cell = {
+   .name = "cros-ec-cec",
+   };
+
+   ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
+   if (ret)
+   dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ 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 handles CEC. */
+   if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+   cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-15 Thread Neil Armstrong
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
 drivers/platform/chrome/cros_ec_proto.c | 42 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 114 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ 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(_dev->event_data, msg->data, 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 *)
+   static int cmd_version = 1;
int ret;
 
+   BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
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(ec_dev->event_data));
+   if (ret != EC_RES_INVALID_VERSION)
+   return ret;
 
-   ret = cros_ec_cmd_xfer(ec_dev, msg);
-   if (ret > 0) {
-   ec_dev->event_size = ret - 1;
-   memcpy(_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 2d4e23c..f3415eb 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..18df466 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_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,
 };
@@ -2093,12 +2101,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_tcec_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_res

[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-15 Thread 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 <narmstr...@baylibre.com>
---
 drivers/gpu/drm/i915/Kconfig  |  1 +
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 12 
 3 files changed, 15 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_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __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 *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..e98103d 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->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->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)->notifier)
+   cec_notifier_put(intel_attached_hdmi(connector)->notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,10 @@ 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->notifier = cec_notifier_get_conn(dev->dev, connector->name);
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

2018-05-15 Thread 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 <narmstr...@baylibre.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(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_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(>lock);
kref_init(>kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_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(>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

_

[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support

2018-05-15 Thread 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 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 (5):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Introduce CEC commands and events definitions.
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: platform: Add Chrome OS EC CEC driver

 drivers/gpu/drm/i915/Kconfig |   1 +
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c|  12 +
 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 | 335 +++
 drivers/mfd/cros_ec_dev.c|  16 ++
 drivers/platform/chrome/cros_ec_proto.c  |  42 ++-
 include/linux/mfd/cros_ec.h  |   2 +-
 include/linux/mfd/cros_ec_commands.h |  80 ++
 include/media/cec-notifier.h |  27 +-
 13 files changed, 526 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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

2018-05-15 Thread Neil Armstrong
Hi,

On 15/05/2018 14:56, Hans Verkuil wrote:
> On 05/15/18 14:46, Neil Armstrong wrote:
>> 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.
> 
> You haven't figured yet out where to place the cec_notifier_put() call?
> Or did you forget?

I just figured it out, I was busy on the CEC driver and notifier, will re-spin 
a v2 with this and the other small fixes you requested.

Thanks,
Neil

> 
> Regards,
> 
>   Hans
> 
>>
>> Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
>> ---
>>  drivers/gpu/drm/i915/Kconfig  |  1 +
>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>>  drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
>>  3 files changed, 13 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_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index d436858..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /**
>>   * __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 *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..9b94d72 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->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->notifier);
>> +
>>  return status;
>>  }
>>  
>> @@ -2358,6 +2364,10 @@ 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->notifier = cec_notifier_get_conn(dev->dev, connector->name);
>> +if (!intel_hdmi->notifier)
>> +DRM_DEBUG_KMS("CEC notifier get failed\n");
>>  }
>>  
>>  void intel_hdmi_init(struct drm_i915_private *dev_priv,
>>
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

2018-05-15 Thread Neil Armstrong
The Chrome OS 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 <narmstr...@baylibre.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 | 336 +++
 4 files changed, 350 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..e55a8ed2 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 "Chrome OS 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
+ Chrome OS 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 000..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 000..bbff5d6
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong <narmstr...@baylibre.com>
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This handles the CEC interface to the ChromeOS Embedded Controller,
+ * but only a single CEC line tied to a single HDMI output is handled now.
+ */
+
+#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, _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 lo

[Intel-gfx] [PATCH 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

2018-05-15 Thread 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 <narmstr...@baylibre.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 eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+   int ret;
+   struct mfd_cell cec_cell = {
+   .name = "cros-ec-cec",
+   };
+
+   ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
+   if (ret)
+   dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ 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 handles CEC. */
+   if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+   cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

2018-05-15 Thread Neil Armstrong
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
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 <sadolfs...@chromium.org>
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
---
 drivers/platform/chrome/cros_ec_proto.c | 42 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 114 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ 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(_dev->event_data, msg->data, 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 *)
+   static int cmd_version = 1;
int ret;
 
+   BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
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(ec_dev->event_data));
+   if (ret != EC_RES_INVALID_VERSION)
+   return ret;
 
-   ret = cros_ec_cmd_xfer(ec_dev, msg);
-   if (ret > 0) {
-   ec_dev->event_size = ret - 1;
-   memcpy(_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 2d4e23c..f3415eb 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..18df466 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_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,
 };
@@ -2093,12 +2101,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_tcec_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_res

  1   2   >