Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4708650imm; Fri, 18 May 2018 09:20:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpouyqn+rL5YMrrgH0BPEDVyMl6WIqIrc7zfum/tL89984adpsvWXgwXPhjYPnyAal7ogck X-Received: by 2002:a65:4c8d:: with SMTP id m13-v6mr8173926pgt.310.1526660418633; Fri, 18 May 2018 09:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526660418; cv=none; d=google.com; s=arc-20160816; b=yVVrWN4+mihrRvXh2MUMLWrGZNIMbTPt2Ze+CEbAO6jhK1RqmuU0piR3rNTICYsEmB /Z8hRCw26kW9OslDR6p+/jJZHuFCgRpkAA8ADGNX9q9Dd0kfzZWp11BOZOAIYc6K4bh7 kD72CVNbyBPX45HWeVkoxVmigu/Z/+xlpYa1mFkGyDfDbcgAgzid7xzNylPexai+6IPd +UjKTjrX9GtoaHnMNdYAqGTtVXMtvhZeiIoAJda1zstIGNcGZNFtvpkaFuwF5aloi+Hn PTgGWIpn0yFMJM1DEHhE9TwqsXK2tnmtJ96GO3Qewa4UpplqUlcIDaWkMg+lztMSduvv lhsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Qxs1hApFaG3T3WiVAfOGUG8pvrvpDhYfNJYqVlCaRvw=; b=gUgYN0f3ELtrJne4hq02rAyhilUSuwhFzHxvtRZich3Eoo/NsxN0A448jcHy64rWPE p/Il1Z4oZZxbzR7bv11K6KH3i1hrEh1coerMkiQlSiCJ+dMpGWMD7e30zUmrWPT1q63d YPczxlVM9Ig3mu5p8sxpJEVhmuGZK/XS3c9hZB7bQdRxN7FqHLJhcbuvda/HUX8yyI9t Zk2KFG2C4sNxvxYwHlp/plcGVVzlVtA2a9i6e3KhACzYRQlQPo3EPLqA9RsXfXrI/IWp v1D+MM5g7kJoY5jb1HL0XCB0n6E7WQqOIYwuuivaC75Irl8GPdvw93e06Bpwg7tiVTCp BGbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ko0JYkh3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14-v6si6186994pgv.514.2018.05.18.09.19.52; Fri, 18 May 2018 09:20:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ko0JYkh3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751581AbeERQT0 (ORCPT + 99 others); Fri, 18 May 2018 12:19:26 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:39981 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbeERQTV (ORCPT ); Fri, 18 May 2018 12:19:21 -0400 Received: by mail-qk0-f195.google.com with SMTP id s83-v6so6872322qke.7; Fri, 18 May 2018 09:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qxs1hApFaG3T3WiVAfOGUG8pvrvpDhYfNJYqVlCaRvw=; b=ko0JYkh3ZmrFeNrOsr65USpFpyZz2kHD3uA61dT1vgUMQ93Bm6In9LqJmBfg2PT6Zz sUDIwJU823gfd4pYXUI/2u2pSc7ZpUfeaYO9hH0NLnCCuf2zVVLM9cQrR0mZiCSjfNP8 9uC+JugrW8kC4KezRlmBSaF09M9BB5SS0IRuJEJ7aS0CruSiq8LP6FYT8MVP0fmYI7PC qKOJTnDcRAc/4xr5ThTnu+yToUzBO2tvKTlWre02/uVjXCImc6YqKWMHFBcMVg0w4lGH Koh9tWMDICdu2iPzcoO/mEvVNy6/jjIUMAN8AIUuzjzb+iTqss4cQfC/u6E4CVaY+cNZ 6VUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qxs1hApFaG3T3WiVAfOGUG8pvrvpDhYfNJYqVlCaRvw=; b=LgwP4l2Kl5MtRzuMdMOBPAcz2okqK2CYlUJy9KpTQyNjJ6c29yuxlq1XlORiwQvxmW uVUy+XHG+6BSrruK2zt34jRlCcF5a+jrCNSnrF1Z8L43rEyyHsA56sUOeSNsfVU+6W6u f1knGGtwrouG7SG6CkpBN0txYS21k1tzbAOu8kJ6LrhA/aMtd24lSxD2LS0yyDCEf4g1 EhjCaMqFpZS9DVaq9XlZ7nzk32q3S5eLccXrcudsvksiuvCCUWl6uYU68eQAcycbpIxi gIwg9GdOKKgKVmMPoyCLYQDaH+pZZy43ocJVLiQ7TKpLcSwGXO+p2Yus6UTefsT31NA9 S7QA== X-Gm-Message-State: ALKqPwcli23pD1vx8zragpHFJT0pgH1mfwQ0aKNoLq+ewC7JQ5mzNhdZ Yq5ZSkAXuww12HDeH+XdwKrQotEkhhtlgUzENo8= X-Received: by 2002:a37:d9da:: with SMTP id q87-v6mr9797978qkl.302.1526660360822; Fri, 18 May 2018 09:19:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.13.68 with HTTP; Fri, 18 May 2018 09:19:20 -0700 (PDT) In-Reply-To: <1526648704-16873-4-git-send-email-narmstrong@baylibre.com> References: <1526648704-16873-1-git-send-email-narmstrong@baylibre.com> <1526648704-16873-4-git-send-email-narmstrong@baylibre.com> From: Enric Balletbo Serra Date: Fri, 18 May 2018 18:19:20 +0200 Message-ID: Subject: Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions. To: Neil Armstrong Cc: David Airlie , Hans Verkuil , Lee Jones , Olof Johansson , Sean Paul , sadolfsson@google.com, Felix Ekblom , Benson Leung , darekm@google.com, =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Fabien Parent , dri-devel , linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-kernel , Stefan Adolfsson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Neil, 2018-05-18 15:05 GMT+02:00 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 > Signed-off-by: Neil Armstrong > --- > 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(&ec_dev->event_data, msg->data, ec_dev->event_size); > + } > + > + return ret; > +} > + > static int get_next_event(struct cros_ec_device *ec_dev) > { > u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)]; > struct cros_ec_command *msg = (struct cros_ec_command *)&buffer; > + static int cmd_version = 1; 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? > int ret; > > if (ec_dev->suspended) { > @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev) > return -EHOSTDOWN; > } > > - msg->version = 0; > - msg->command = EC_CMD_GET_NEXT_EVENT; > - msg->insize = sizeof(ec_dev->event_data); > - msg->outsize = 0; > + if (cmd_version == 1) { > + ret = get_next_event_xfer(ec_dev, msg, cmd_version, > + sizeof(struct ec_response_get_next_event_v1)); > + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION) > + return ret; > > - ret = cros_ec_cmd_xfer(ec_dev, msg); > - if (ret > 0) { > - ec_dev->event_size = ret - 1; > - memcpy(&ec_dev->event_data, msg->data, > - sizeof(ec_dev->event_data)); > + /* Fallback to version 0 for future send attempts */ > + cmd_version = 0; > } > 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. > + 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 This file is going to be very big and as requested by Lee I plan to convert this file to the kernel-doc format, this patch introduces some new structs so could you document the new structs in the suggested format? > @@ -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_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 > @@ -2828,6 +2855,59 @@ struct ec_params_reboot_ec { > /* Current version of ACPI memory address space */ > #define EC_ACPI_MEM_VERSION_CURRENT 1 > > +/*****************************************************************************/ > +/* > + * 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 > + > +/* Message 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 { > + 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 { > + uint8_t cmd; /* enum cec_command */ > +} __packed; > + > +struct ec_response_cec_get { > + union { > + uint8_t enable; > + uint8_t address; > + }; > +} __packed; > + > +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 = 1 << 0, > + EC_MKBP_CEC_SEND_FAILED = 1 << 1, Use the BIT() macro. > +}; > > /*****************************************************************************/ > /* > -- > 2.7.4 > Thanks, Enric