Home
last modified time | relevance | path

Searched +full:cros +full:- +full:ec +full:- +full:i2c (Results 1 – 25 of 61) sorted by relevance

123

/kernel/linux/linux-5.10/Documentation/devicetree/bindings/mfd/
Dgoogle,cros-ec.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/mfd/google,cros-ec.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Benson Leung <bleung@chromium.org>
11 - Enric Balletbo i Serra <enric.balletbo@collabora.com>
12 - Guenter Roeck <groeck@chromium.org>
15 Google's ChromeOS EC is a microcontroller which talks to the AP and
17 The EC can be connected through various interfaces (I2C, SPI, and others)
23 - description:
[all …]
/kernel/linux/linux-5.10/Documentation/devicetree/bindings/i2c/
Dgoogle,cros-ec-i2c-tunnel.yaml1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
5 $id: http://devicetree.org/schemas/i2c/google,cros-ec-i2c-tunnel.yaml#
6 $schema: http://devicetree.org/meta-schemas/core.yaml#
8 title: I2C bus that tunnels through the ChromeOS EC (cros-ec)
11 - Doug Anderson <dianders@chromium.org>
12 - Benson Leung <bleung@chromium.org>
13 - Enric Balletbo i Serra <enric.balletbo@collabora.com>
16 On some ChromeOS board designs we've got a connection to the EC
18 other side of the EC (like a battery and PMIC). To get access to
[all …]
/kernel/linux/linux-4.19/Documentation/devicetree/bindings/i2c/
Di2c-cros-ec-tunnel.txt1 I2C bus that tunnels through the ChromeOS EC (cros-ec)
3 On some ChromeOS board designs we've got a connection to the EC (embedded
5 the EC (like a battery and PMIC). To get access to those devices we need
6 to tunnel our i2c commands through the EC.
8 The node for this device should be under a cros-ec node like google,cros-ec-spi
9 or google,cros-ec-i2c.
13 - compatible: google,cros-ec-i2c-tunnel
14 - google,remote-bus: The EC bus we'd like to talk to.
17 - One node per I2C device connected to the tunnelled I2C bus.
21 cros-ec@0 {
[all …]
/kernel/linux/linux-4.19/Documentation/devicetree/bindings/mfd/
Dcros-ec.txt3 Google's ChromeOS EC is a Cortex-M device which talks to the AP and
6 The EC can be connect through various means (I2C, SPI, LPC) and the
8 its own driver which connects to the top level interface-agnostic EC driver.
9 Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
10 the top-level driver.
12 Required properties (I2C):
13 - compatible: "google,cros-ec-i2c"
14 - reg: I2C slave address
17 - compatible: "google,cros-ec-spi"
18 - reg: SPI chip select
[all …]
/kernel/linux/linux-4.19/Documentation/devicetree/bindings/extcon/
Dextcon-usbc-cros-ec.txt1 ChromeOS EC USB Type-C cable and accessories detection
7 The node for this device must be under a cros-ec node like google,cros-ec-spi
8 or google,cros-ec-i2c.
11 - compatible: Should be "google,extcon-usbc-cros-ec".
12 - google,usb-port-id: Specifies the USB port ID to use.
15 cros-ec@0 {
16 compatible = "google,cros-ec-i2c";
21 compatible = "google,extcon-usbc-cros-ec";
22 google,usb-port-id = <0>;
/kernel/linux/linux-5.10/Documentation/devicetree/bindings/extcon/
Dextcon-usbc-cros-ec.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/extcon/extcon-usbc-cros-ec.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: ChromeOS EC USB Type-C cable and accessories detection
10 - Benson Leung <bleung@chromium.org>
11 - Enric Balletbo i Serra <enric.balletbo@collabora.com>
17 The node for this device must be under a cros-ec node like google,cros-ec-spi
18 or google,cros-ec-i2c.
22 const: google,extcon-usbc-cros-ec
[all …]
/kernel/linux/linux-5.10/drivers/i2c/busses/
Di2c-cros-ec-tunnel.c1 // SPDX-License-Identifier: GPL-2.0+
2 // Expose an I2C passthrough to the ChromeOS EC.
8 #include <linux/i2c.h>
17 * struct ec_i2c_device - Driver data for I2C tunnel
20 * @adap: I2C adapter
21 * @ec: Pointer to EC device
22 * @remote_bus: The EC bus number we tunnel to on the other side.
30 struct cros_ec_device *ec; member
39 * ec_i2c_count_message - Count bytes needed for ec_i2c_construct_message
41 * @i2c_msgs: The i2c messages to read
[all …]
/kernel/linux/linux-4.19/drivers/i2c/busses/
Di2c-cros-ec-tunnel.c9 * Expose an I2C passthrough to the ChromeOS EC.
13 #include <linux/i2c.h>
22 * struct ec_i2c_device - Driver data for I2C tunnel
25 * @adap: I2C adapter
26 * @ec: Pointer to EC device
27 * @remote_bus: The EC bus number we tunnel to on the other side.
35 struct cros_ec_device *ec; member
44 * ec_i2c_count_message - Count bytes needed for ec_i2c_construct_message
46 * @i2c_msgs: The i2c messages to read
47 * @num: The number of i2c messages.
[all …]
/kernel/linux/linux-5.10/arch/arm/boot/dts/
Drk3288-veyron-chromebook.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
9 #include <dt-bindings/clock/rockchip,rk808.h>
10 #include <dt-bindings/input/input.h>
11 #include "rk3288-veyron.dtsi"
12 #include "rk3288-veyron-analog-audio.dtsi"
13 #include "rk3288-veyron-edp.dtsi"
14 #include "rk3288-veyron-sdmmc.dtsi"
22 gpio-charger {
23 compatible = "gpio-charger";
24 charger-type = "mains";
[all …]
Dtegra124-nyan.dtsi1 // SPDX-License-Identifier: GPL-2.0
2 #include <dt-bindings/input/input.h>
7 rtc0 = "/i2c@7000d000/pmic@40";
13 stdout-path = "serial0:115200n8";
19 * missing a unit-address. However, the bootloader on these Chromebook
21 * Adding the unit-address causes the bootloader to create a /memory
33 /delete-node/ memory@80000000;
39 vdd-supply = <&vdd_3v3_hdmi>;
40 pll-supply = <&vdd_hdmi_pll>;
41 hdmi-supply = <&vdd_5v0_hdmi>;
[all …]
/kernel/linux/linux-4.19/arch/arm/boot/dts/
Drk3288-veyron-chromebook.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
9 #include <dt-bindings/clock/rockchip,rk808.h>
10 #include <dt-bindings/input/input.h>
11 #include "rk3288-veyron.dtsi"
12 #include "rk3288-veyron-analog-audio.dtsi"
13 #include "rk3288-veyron-sdmmc.dtsi"
22 compatible = "pwm-backlight";
23 brightness-levels = <
56 default-brightness-level = <128>;
57 enable-gpios = <&gpio7 RK_PA2 GPIO_ACTIVE_HIGH>;
[all …]
Dtegra124-nyan.dtsi1 // SPDX-License-Identifier: GPL-2.0
2 #include <dt-bindings/input/input.h>
7 rtc0 = "/i2c@7000d000/pmic@40";
13 stdout-path = "serial0:115200n8";
19 * missing a unit-address. However, the bootloader on these Chromebook
21 * Adding the unit-address causes the bootloader to create a /memory
33 /delete-node/ memory@80000000;
39 vdd-supply = <&vdd_3v3_hdmi>;
40 pll-supply = <&vdd_hdmi_pll>;
41 hdmi-supply = <&vdd_5v0_hdmi>;
[all …]
/kernel/linux/linux-4.19/arch/arm64/boot/dts/rockchip/
Drk3399-gru.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
5 * Copyright 2016-2017 Google, Inc
8 #include <dt-bindings/input/input.h>
10 #include "rk3399-op1-opp.dtsi"
14 stdout-path = "serial2:115200n8";
23 * - Rails that only connect to the EC (or devices that the EC talks to)
25 * - Rails _are_ included if the rails go to the AP even if the AP
34 * - The EC controls the enable and the EC always enables a rail as
36 * - The rails are actually connected to each other by a jumper and
41 ppvar_sys: ppvar-sys {
[all …]
Drk3399-gru-chromebook.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
3 * Google Gru-Chromebook shared properties
8 #include "rk3399-gru.dtsi"
11 pp900_ap: pp900-ap {
12 compatible = "regulator-fixed";
13 regulator-name = "pp900_ap";
15 /* EC turns on w/ pp900_ap_en; always on for AP */
16 regulator-always-on;
17 regulator-boot-on;
18 regulator-min-microvolt = <900000>;
[all …]
/kernel/linux/linux-5.10/arch/arm64/boot/dts/rockchip/
Drk3399-gru.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
5 * Copyright 2016-2017 Google, Inc
8 #include <dt-bindings/input/input.h>
10 #include "rk3399-op1-opp.dtsi"
14 stdout-path = "serial2:115200n8";
23 * - Rails that only connect to the EC (or devices that the EC talks to)
25 * - Rails _are_ included if the rails go to the AP even if the AP
34 * - The EC controls the enable and the EC always enables a rail as
36 * - The rails are actually connected to each other by a jumper and
41 ppvar_sys: ppvar-sys {
[all …]
Drk3399-gru-chromebook.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
3 * Google Gru-Chromebook shared properties
8 #include "rk3399-gru.dtsi"
11 pp900_ap: pp900-ap {
12 compatible = "regulator-fixed";
13 regulator-name = "pp900_ap";
15 /* EC turns on w/ pp900_ap_en; always on for AP */
16 regulator-always-on;
17 regulator-boot-on;
18 regulator-min-microvolt = <900000>;
[all …]
/kernel/linux/linux-5.10/drivers/platform/chrome/
Dcros_ec_i2c.c1 // SPDX-License-Identifier: GPL-2.0
2 // I2C interface for ChromeOS Embedded Controller
10 #include <linux/i2c.h>
22 * byte 1-8 struct ec_host_request
23 * byte 10- response data
36 * byte 2-9 struct ec_host_response
37 * byte 10- response data
55 struct i2c_client *client = ec_dev->priv; in cros_ec_pkt_xfer_i2c()
56 int ret = -ENOMEM; in cros_ec_pkt_xfer_i2c()
69 i2c_msg[0].addr = client->addr; in cros_ec_pkt_xfer_i2c()
[all …]
Dcros_ec_spi.c1 // SPDX-License-Identifier: GPL-2.0
23 * Number of EC preamble bytes we read at a time. Since it takes
24 * about 400-500us for the EC to respond there is not a lot of
25 * point in tuning this. If the EC could respond faster then
34 * Allow for a long time for the EC to respond. We support i2c
43 * not directly passing i2c through, but it's too late for that for
50 * for this, clocking in at 2-3ms.
57 * If we go too fast, the EC will miss the transaction. We know that we
58 * need at least 70 us with the 16 MHz STM32 EC, so go with 200 us to be
64 * struct cros_ec_spi - information about a SPI-connected EC
[all …]
/kernel/linux/linux-4.19/drivers/platform/chrome/
Dcros_ec_i2c.c2 * ChromeOS EC multi-function device (I2C)
20 #include <linux/i2c.h>
30 * byte 1-8 struct ec_host_request
31 * byte 10- response data
44 * byte 2-9 struct ec_host_response
45 * byte 10- response data
63 struct i2c_client *client = ec_dev->priv; in cros_ec_pkt_xfer_i2c()
64 int ret = -ENOMEM; in cros_ec_pkt_xfer_i2c()
77 i2c_msg[0].addr = client->addr; in cros_ec_pkt_xfer_i2c()
79 i2c_msg[1].addr = client->addr; in cros_ec_pkt_xfer_i2c()
[all …]
Dcros_ec_spi.c2 * ChromeOS EC multi-function device (SPI)
31 * Number of EC preamble bytes we read at a time. Since it takes
32 * about 400-500us for the EC to respond there is not a lot of
33 * point in tuning this. If the EC could respond faster then
42 * Allow for a long time for the EC to respond. We support i2c
51 * not directly passing i2c through, but it's too late for that for
58 * for this, clocking in at 2-3ms.
65 * If we go too fast, the EC will miss the transaction. We know that we
66 * need at least 70 us with the 16 MHz STM32 EC, so go with 200 us to be
72 * struct cros_ec_spi - information about a SPI-connected EC
[all …]
/kernel/linux/linux-5.10/include/linux/platform_data/
Dcros_ec_proto.h1 /* SPDX-License-Identifier: GPL-2.0 */
25 * The EC is unresponsive for a time after a reboot command. Add a
31 * Max bus-specific overhead incurred by request/responses.
32 * I2C requires 1 additional byte for requests.
33 * I2C requires 2 additional bytes for responses.
41 * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
58 * struct cros_ec_command - Information about a ChromeOS EC command.
62 * @insize: Max number of bytes to accept from the EC.
63 * @result: EC's response to the command (separate from communication failure).
64 * @data: Where to put the incoming data from EC and outgoing data to EC.
[all …]
/kernel/linux/linux-4.19/include/linux/mfd/
Dcros_ec.h2 * ChromeOS EC multi-function device
29 * The EC is unresponsive for a time after a reboot command. Add a
35 * Max bus-specific overhead incurred by request/responses.
36 * I2C requires 1 additional byte for requests.
37 * I2C requires 2 additional bytes for responses.
45 * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
65 * @insize: Max number of bytes to accept from EC
66 * @result: EC's response to the command (separate from communication failure)
67 * @data: Where to put the incoming data from EC and outgoing data to EC
79 * struct cros_ec_device - Information about a ChromeOS EC device
[all …]
/kernel/linux/linux-5.10/arch/arm64/boot/dts/mediatek/
Dmt8183-kukui.dtsi1 // SPDX-License-Identifier: (GPL-2.0 OR MIT)
8 #include <dt-bindings/gpio/gpio.h>
9 #include <dt-bindings/input/input.h>
19 stdout-path = "serial0:115200n8";
28 compatible = "fixed-clock";
29 #clock-cells = <0>;
30 clock-frequency = <32768>;
31 clock-output-names = "clk32k";
35 compatible = "regulator-fixed";
36 regulator-name = "it6505_pp18";
[all …]
/kernel/linux/linux-5.10/arch/arm64/boot/dts/qcom/
Dsc7180-trogdor.dtsi1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
8 #include <dt-bindings/gpio/gpio.h>
9 #include <dt-bindings/input/input.h>
10 #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
23 /delete-node/ &hyp_mem;
24 /delete-node/ &xbl_mem;
25 /delete-node/ &aop_mem;
26 /delete-node/ &sec_apps_mem;
27 /delete-node/ &tz_mem;
35 reserved-memory {
[all …]
/kernel/linux/linux-4.19/drivers/input/keyboard/
Dcros_ec_keyb.c1 // SPDX-License-Identifier: GPL-2.0
2 // ChromeOS EC keyboard driver
6 // This driver uses the ChromeOS EC byte-level message-based protocol for
7 // communicating the keyboard state (which keys are pressed) from a keyboard EC
8 // to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
10 // motivation for this is to keep the EC firmware as simple as possible, since
11 // it cannot be easily upgraded and EC flash/IRAM space is relatively
16 #include <linux/i2c.h>
35 * @ghost_filter: true to enable the matrix key-ghosting filter
39 * @ec: Top level ChromeOS device to use to talk to EC
[all …]

123