Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Hello, On 01/30/2015 01:51 PM, Javier Martinez Canillas wrote: > On 01/29/2015 10:11 PM, Paul Bolle wrote: >>> + help >>> + If you say Y here, you get support for talking to the ChromeOS EC >>> + over an LPC bus. This uses a simple byte-level protocol with a >>> + checksum. This is used for userspace access only. The kernel >>> + typically has its own communication methods. >>> + >> >> What happens when you say M? >> > > Since it is a tristate kconfig symbol, it can be built as a kernel module > but since there isn't a LPC subsystem, the platform device is registered > in the module_init() function. So, building as a module is trickier since > there won't be an uevent that can trigger a module auto-load based on the > modinfo aliases information. > FYI, I noticed that other x86 platform drivers use the dmi system information to fill dmi modaliases so the modules are auto-loaded. So I did the same and posted a new version 5 [0] of this series. Best regards, Javier [0]: https://lkml.org/lkml/2015/2/2/214 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Hello, On 01/30/2015 01:51 PM, Javier Martinez Canillas wrote: On 01/29/2015 10:11 PM, Paul Bolle wrote: + help + If you say Y here, you get support for talking to the ChromeOS EC + over an LPC bus. This uses a simple byte-level protocol with a + checksum. This is used for userspace access only. The kernel + typically has its own communication methods. + What happens when you say M? Since it is a tristate kconfig symbol, it can be built as a kernel module but since there isn't a LPC subsystem, the platform device is registered in the module_init() function. So, building as a module is trickier since there won't be an uevent that can trigger a module auto-load based on the modinfo aliases information. FYI, I noticed that other x86 platform drivers use the dmi system information to fill dmi modaliases so the modules are auto-loaded. So I did the same and posted a new version 5 [0] of this series. Best regards, Javier [0]: https://lkml.org/lkml/2015/2/2/214 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Hello Paul, Thanks a lot for your feedback. On 01/29/2015 10:11 PM, Paul Bolle wrote: >> >> +config CROS_EC_LPC >> +tristate "ChromeOS Embedded Controller (LPC)" >> +depends on MFD_CROS_EC >> + > > Please drop this empty line. > Ok. >> +help >> + If you say Y here, you get support for talking to the ChromeOS EC >> + over an LPC bus. This uses a simple byte-level protocol with a >> + checksum. This is used for userspace access only. The kernel >> + typically has its own communication methods. >> + > > What happens when you say M? > Since it is a tristate kconfig symbol, it can be built as a kernel module but since there isn't a LPC subsystem, the platform device is registered in the module_init() function. So, building as a module is trickier since there won't be an uevent that can trigger a module auto-load based on the modinfo aliases information. One can of course force udev to load the module by adding to modules.conf or such but I wonder if is better to change from tristate to boolean or add to the help that it can be built as a module but auto-load does not work in that case. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Hello Paul, Thanks a lot for your feedback. On 01/29/2015 10:11 PM, Paul Bolle wrote: +config CROS_EC_LPC +tristate ChromeOS Embedded Controller (LPC) +depends on MFD_CROS_EC + Please drop this empty line. Ok. +help + If you say Y here, you get support for talking to the ChromeOS EC + over an LPC bus. This uses a simple byte-level protocol with a + checksum. This is used for userspace access only. The kernel + typically has its own communication methods. + What happens when you say M? Since it is a tristate kconfig symbol, it can be built as a kernel module but since there isn't a LPC subsystem, the platform device is registered in the module_init() function. So, building as a module is trickier since there won't be an uevent that can trigger a module auto-load based on the modinfo aliases information. One can of course force udev to load the module by adding to modules.conf or such but I wonder if is better to change from tristate to boolean or add to the help that it can be built as a module but auto-load does not work in that case. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Javier, Trivial nits below. On Thu, 2015-01-29 at 14:37 +0100, Javier Martinez Canillas wrote: > From: Bill Richardson > > Chromebooks have an Embedded Controller (EC) that is used to > implement various functions such as keyboard, power and battery. > > The AP can communicate with the EC through different bus types > such as I2C, SPI or LPC. > > The cros_ec mfd driver is then composed of a core driver that > register the sub-devices as mfd cells and provide a high level > communication interface that is used by the rest of the kernel > and bus specific interfaces modules. > > Each connection method then has its own driver, which register > with the EC driver interface-agnostic interface. > > Currently, there are drivers to communicate with the EC over > I2C and SPI and this driver adds support for LPC. > > Signed-off-by: Bill Richardson > Signed-off-by: Javier Martinez Canillas > [...] > drivers/misc/Kconfig | 10 ++ > drivers/misc/Makefile | 1 + > drivers/misc/cros_ec_lpc.c | 291 > + > 3 files changed, 302 insertions(+) > create mode 100644 drivers/misc/cros_ec_lpc.c > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 006242c8bca0..142393e84a43 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG > bus. System Configuration interface is one of the possible means > of generating transactions on this bus. > > +config CROS_EC_LPC > + tristate "ChromeOS Embedded Controller (LPC)" > + depends on MFD_CROS_EC > + Please drop this empty line. > + help > + If you say Y here, you get support for talking to the ChromeOS EC > + over an LPC bus. This uses a simple byte-level protocol with a > + checksum. This is used for userspace access only. The kernel > + typically has its own communication methods. > + What happens when you say M? > source "drivers/misc/c2port/Kconfig" > source "drivers/misc/eeprom/Kconfig" > source "drivers/misc/cb710/Kconfig" Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
On Thu, Jan 29, 2015 at 7:07 PM, Javier Martinez Canillas
wrote:
> From: Bill Richardson
>
> Chromebooks have an Embedded Controller (EC) that is used to
> implement various functions such as keyboard, power and battery.
>
> The AP can communicate with the EC through different bus types
> such as I2C, SPI or LPC.
>
> The cros_ec mfd driver is then composed of a core driver that
> register the sub-devices as mfd cells and provide a high level
> communication interface that is used by the rest of the kernel
> and bus specific interfaces modules.
>
> Each connection method then has its own driver, which register
> with the EC driver interface-agnostic interface.
>
> Currently, there are drivers to communicate with the EC over
> I2C and SPI and this driver adds support for LPC.
>
> Signed-off-by: Bill Richardson
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v3:
> - Rename MYNAME to DRV_NAME
> - Use devm_request_region() instead of request_region.
>Suggested by Varka Bhadram.
> - Remove release_region from cleanup handle logic by using devres API.
>Suggested by Varka Bhadram.
> - Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
>
Addressed all of my comments... Thanks
Reviewed-by: Varka Bhadram
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
From: Bill Richardson
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson
Signed-off-by: Javier Martinez Canillas
---
Changes since v3:
- Rename MYNAME to DRV_NAME
- Use devm_request_region() instead of request_region.
Suggested by Varka Bhadram.
- Remove release_region from cleanup handle logic by using devres API.
Suggested by Varka Bhadram.
- Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
Changes since v2:
- Move out from drivers/mfd to drivers/misc. Suggested by Lee Jones.
Changes since v1: None, new patch.
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_lpc.c | 291 +
3 files changed, 302 insertions(+)
create mode 100644 drivers/misc/cros_ec_lpc.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c8bca0..142393e84a43 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config CROS_EC_LPC
+ tristate "ChromeOS Embedded Controller (LPC)"
+ depends on MFD_CROS_EC
+
+ help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ over an LPC bus. This uses a simple byte-level protocol with a
+ checksum. This is used for userspace access only. The kernel
+ typically has its own communication methods.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7d5c4cd118c4..37a9647e7900 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,4 +55,5 @@ obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
+obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/cros_ec_lpc.c b/drivers/misc/cros_ec_lpc.c
new file mode 100644
index ..ff6ce5e489c4
--- /dev/null
+++ b/drivers/misc/cros_ec_lpc.c
@@ -0,0 +1,291 @@
+/*
+ * cros_ec_lpc - LPC access to the Chrome OS Embedded Controller
+ *
+ * Copyright (C) 2012-2015 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard EC
+ * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
+ * but everything else (including deghosting) is done here. The main
+ * motivation for this is to keep the EC firmware as simple as possible, since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros_ec_lpc"
+
+static int ec_response_timed_out(void)
+{
+ unsigned long one_second = jiffies + HZ;
+
+ usleep_range(200, 300);
+ do {
+ if (!(inb(EC_LPC_ADDR_HOST_CMD) & EC_LPC_STATUS_BUSY_MASK))
+ return 0;
+ usleep_range(100, 200);
+ } while (time_before(jiffies, one_second));
+
+ return 1;
+}
+
+static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
+ struct cros_ec_command *msg)
+{
+ struct ec_lpc_host_args args;
+ int csum;
+ int i;
+ int ret = 0;
+
+ if (msg->outsize > EC_PROTO2_MAX_PARAM_SIZE ||
+ msg->insize > EC_PROTO2_MAX_PARAM_SIZE) {
+ dev_err(ec->dev,
+ "invalid buffer sizes (out %d, in %d)\n",
+ msg->outsize, msg->insize);
+ return -EINVAL;
+ }
+
+ /* Now actually send the command to the EC
[PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
From: Bill Richardson wfric...@chromium.org
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Rename MYNAME to DRV_NAME
- Use devm_request_region() instead of request_region.
Suggested by Varka Bhadram.
- Remove release_region from cleanup handle logic by using devres API.
Suggested by Varka Bhadram.
- Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
Changes since v2:
- Move out from drivers/mfd to drivers/misc. Suggested by Lee Jones.
Changes since v1: None, new patch.
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec_lpc.c | 291 +
3 files changed, 302 insertions(+)
create mode 100644 drivers/misc/cros_ec_lpc.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c8bca0..142393e84a43 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config CROS_EC_LPC
+ tristate ChromeOS Embedded Controller (LPC)
+ depends on MFD_CROS_EC
+
+ help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ over an LPC bus. This uses a simple byte-level protocol with a
+ checksum. This is used for userspace access only. The kernel
+ typically has its own communication methods.
+
source drivers/misc/c2port/Kconfig
source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7d5c4cd118c4..37a9647e7900 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,4 +55,5 @@ obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
+obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/cros_ec_lpc.c b/drivers/misc/cros_ec_lpc.c
new file mode 100644
index ..ff6ce5e489c4
--- /dev/null
+++ b/drivers/misc/cros_ec_lpc.c
@@ -0,0 +1,291 @@
+/*
+ * cros_ec_lpc - LPC access to the Chrome OS Embedded Controller
+ *
+ * Copyright (C) 2012-2015 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard EC
+ * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
+ * but everything else (including deghosting) is done here. The main
+ * motivation for this is to keep the EC firmware as simple as possible, since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include linux/delay.h
+#include linux/mfd/cros_ec.h
+#include linux/mfd/cros_ec_commands.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/printk.h
+
+#define DRV_NAME cros_ec_lpc
+
+static int ec_response_timed_out(void)
+{
+ unsigned long one_second = jiffies + HZ;
+
+ usleep_range(200, 300);
+ do {
+ if (!(inb(EC_LPC_ADDR_HOST_CMD) EC_LPC_STATUS_BUSY_MASK))
+ return 0;
+ usleep_range(100, 200);
+ } while (time_before(jiffies, one_second));
+
+ return 1;
+}
+
+static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
+ struct cros_ec_command *msg)
+{
+ struct ec_lpc_host_args args;
+ int csum;
+ int i;
+ int ret = 0;
+
+ if (msg-outsize EC_PROTO2_MAX_PARAM_SIZE ||
+ msg-insize EC_PROTO2_MAX_PARAM_SIZE) {
+ dev_err(ec-dev,
+ invalid buffer sizes
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
On Thu, Jan 29, 2015 at 7:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
From: Bill Richardson wfric...@chromium.org
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Rename MYNAME to DRV_NAME
- Use devm_request_region() instead of request_region.
Suggested by Varka Bhadram.
- Remove release_region from cleanup handle logic by using devres API.
Suggested by Varka Bhadram.
- Use {dev,pr}_err() instead of {dev,pr}_warn() to log errors.
Addressed all of my comments... Thanks
Reviewed-by: Varka Bhadram varkabhad...@gmail.com
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices
Javier, Trivial nits below. On Thu, 2015-01-29 at 14:37 +0100, Javier Martinez Canillas wrote: From: Bill Richardson wfric...@chromium.org Chromebooks have an Embedded Controller (EC) that is used to implement various functions such as keyboard, power and battery. The AP can communicate with the EC through different bus types such as I2C, SPI or LPC. The cros_ec mfd driver is then composed of a core driver that register the sub-devices as mfd cells and provide a high level communication interface that is used by the rest of the kernel and bus specific interfaces modules. Each connection method then has its own driver, which register with the EC driver interface-agnostic interface. Currently, there are drivers to communicate with the EC over I2C and SPI and this driver adds support for LPC. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk [...] drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile | 1 + drivers/misc/cros_ec_lpc.c | 291 + 3 files changed, 302 insertions(+) create mode 100644 drivers/misc/cros_ec_lpc.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 006242c8bca0..142393e84a43 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -515,6 +515,16 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config CROS_EC_LPC + tristate ChromeOS Embedded Controller (LPC) + depends on MFD_CROS_EC + Please drop this empty line. + help + If you say Y here, you get support for talking to the ChromeOS EC + over an LPC bus. This uses a simple byte-level protocol with a + checksum. This is used for userspace access only. The kernel + typically has its own communication methods. + What happens when you say M? source drivers/misc/c2port/Kconfig source drivers/misc/eeprom/Kconfig source drivers/misc/cb710/Kconfig Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
