Message ID | 20191115093412.144922-1-gwendal@chromium.org (mailing list archive) |
---|---|
Headers | show |
Series | cros_ec: Add sensorhub driver and FIFO processing | expand |
Hi, On 15/11/19 10:33, Gwendal Grignou wrote: > This patchset adds a sensorhub driver for spreading sensor > events coming from the Embedded controller sensor FIFO: > > +---------------+ +--------------+ +---- > | cros_ec_accel | | cros_ec_gyro | | ... > +---------------+ +--------------+ +---- > id:0 \ id:1 | / id:.. > +------------------------------+ > | cros_ec_sensorhub | > +------------------------------+ > | cros_ec_dev | > +------------------------------+ > | cros_ec_i2c, cros_ec_lpc, .. | > +------------------------------+ > | > EC > > When new sensors events are present, the EC raises and interrupt, > sensorhub reads the FIFO and uses the 'id' field to spread the event to > the proper IIO sensors. This stack is similar to the HID sensor input > stack. > > The first patch move cros_ec_proto functions documentations into the > code to prevent rot. > > The inext 3 patches add a primitive cros_ec_sensorhub. MFD just have to > register this driver if at least one sensor is presented by the EC. > cros_ec_sensorhub retrieves more information from the EC to find out > which sensors are actually present: > mfd: cros_ec: Add sensor_count and make check_features public > platform: cros_ec: Add cros_ec_sensor_hub driver > platform/mfd:iio: cros_ec: Register sensor through sensorhub > > The next 3 patches prepare for FIFO support: > platform: chrome: cros-ec: record event timestamp in the hard irq > platform: chrome: cros_ec: Do not attempt to register a non-positive > platform: chrome: cros_ec: handle MKBP more events flag > > That last patch fixes a regression that changes event processing. > Revert the patches that fixed that regression. > > The next 3 patches add FIFO support. An interface is added to connect > the IIO sensors with cros_ec_sensorhub, and filters are needed to spread > the timestamp when the EC send batches of events and deal with variation > in interrupt delay. > platform: chrome: sensorhub: Add FIFO support > platform: chrome: sensorhub: Add code to spread timestmap > platform: chrome: sensorhub: Add median filter > > The remaining patches update IIO cros_ec drivers: > The first patch moves cros_ec_sensor_core functions documentation into > the .c file. > The second one exports iio_device_set_clock, so that the timestamp > generated by the FIFO matches the default timestamp exposed by the IIO > devices. > Then we can use the FIFO function exposed by cros_ec_sensorhub: > iio: cros_ec: Use triggered buffer only when EC does not support FIFO > > The power management functions are not necessary anymore, since we > shutoff the FIFO from cros_ec_sensorhub: > iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO > > Finally, the last 3 patches present sensor information following the IIO > ABI: > - Configurable EC timeout to allow batch mode in buffer/hwfifo_timeout, > in seconds. > - Hard coded EC FIFO size in buffer/hwfifo_watermark_max > - Sensor sampling frequency in hertz at sampling_frequency: > iio: cros_ec: Expose hwfifo_timeout > iio: cros_ec: Report hwfifo_watermark_max > iio: cros_ec: Use Hertz as unit for sampling frequency > > For testing, libiio test tools can be used: > A iio device link looks like: > iio:device1 -> > ...09:00/GOOG0004:00/cros-ec-dev.6.auto/cros-ec-sensorhub.7.auto/ > cros-ec-accel.15.auto/iio:device1 > > When FIFO is available, no trigger are presented. Once > sampling_freqeuncy and hwfifo_timeout are set, sensor events flow > when listening to /dev/iio:device1: > echo 12 > sampling_frequency # Set ODR to at least 12Hz > echo .100 > buffer/hwfifo_timeout # do not wait more than 100ms to > # to send samples > iio_readdev -b 2 -T 1000 -s 2 iio:device1 2>/dev/null| od -x > 0000000 ffd0 2e20 d990 0000 8630 b56c 07ea 0000 > 0000020 ffc0 2e10 d970 0000 877e b56c 07ea 0000 > 0000040` > > When FIFO is not supported by the EC, a trigger is present in the > directory. After registering a trigger, setting sampling_frequency, > the latest data collected by the sensor will be retrieved by the host > when the trigger expires. > > When cros_ec_accel_legacy driver is used, no FIFO is supported and the > sampling frequency for the accelerometers is hard coded at 10Hz. > > This set is built upon the master branch of > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > Enrico Granata (2): > platform: chrome: cros_ec: Do not attempt to register a non-positive > IRQ number > platform: chrome: cros_ec: handle MKBP more events flag > > Gwendal Grignou (16): > mfd: cros_ec: Add sensor_count and make check_features public > platform: cros_ec: Add cros_ec_sensor_hub driver > platform/mfd:iio: cros_ec: Register sensor through sensorhub > platform: chrome: cros-ec: record event timestamp in the hard irq > Revert "Input: cros_ec_keyb - add back missing mask for event_type" > Revert "Input: cros_ec_keyb: mask out extra flags in event_type" > platform: chrome: sensorhub: Add FIFO support > platform: chrome: sensorhub: Add code to spread timestmap > platform: chrome: sensorhub: Add median filter > iio: cros_ec: Move function description to .c file > iio: expose iio_device_set_clock > iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO > iio: cros_ec: Remove pm function > iio: cros_ec: Expose hwfifo_timeout > iio: cros_ec: Report hwfifo_watermark_max > iio: cros_ec: Use Hertz as unit for sampling frequency > > drivers/iio/accel/cros_ec_accel_legacy.c | 14 +- > drivers/iio/common/cros_ec_sensors/Kconfig | 2 +- > .../cros_ec_sensors/cros_ec_lid_angle.c | 3 +- > .../common/cros_ec_sensors/cros_ec_sensors.c | 19 +- > .../cros_ec_sensors/cros_ec_sensors_core.c | 359 +++++-- > drivers/iio/industrialio-core.c | 8 +- > drivers/iio/light/cros_ec_light_prox.c | 21 +- > drivers/iio/pressure/cros_ec_baro.c | 14 +- > drivers/input/keyboard/cros_ec_keyb.c | 6 +- > drivers/mfd/cros_ec_dev.c | 235 +---- > drivers/platform/chrome/Kconfig | 12 + > drivers/platform/chrome/Makefile | 2 + > drivers/platform/chrome/cros_ec.c | 51 +- > drivers/platform/chrome/cros_ec_ishtp.c | 25 +- > drivers/platform/chrome/cros_ec_lpc.c | 17 +- > drivers/platform/chrome/cros_ec_proto.c | 197 +++- > drivers/platform/chrome/cros_ec_rpmsg.c | 19 +- > drivers/platform/chrome/cros_ec_sensorhub.c | 249 +++++ > .../platform/chrome/cros_ec_sensorhub_ring.c | 987 ++++++++++++++++++ > .../linux/iio/common/cros_ec_sensors_core.h | 104 +- > include/linux/iio/iio.h | 2 + > include/linux/platform_data/cros_ec_proto.h | 41 +- > .../linux/platform_data/cros_ec_sensorhub.h | 196 ++++ > 23 files changed, 2054 insertions(+), 529 deletions(-) > create mode 100644 drivers/platform/chrome/cros_ec_sensorhub.c > create mode 100644 drivers/platform/chrome/cros_ec_sensorhub_ring.c > create mode 100644 include/linux/platform_data/cros_ec_sensorhub.h > After having patches 1 to 8 on linux-next for one week I queued those for 5.5. For 9/10/11 I have still comments to do, so will go probably for 5.6. Lee, Jonathan and Dmitry, I created an immutable branch for those * https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/tag/?h=tag-ib-chrome-mfd-iio-input-5.5 But you probably can skip to merge that branch if you don't plan to queue more patches for 5.5. I tested with your next branches and merges cleanly. It is also on my plans wait at least one week more to do the chrome-platform PR to Linus so the patches are one week more in linux-next. Thanks, Enric