Re: [PATCH v5 00/18] cros_ec: Add sensorhub driver and FIFO processing

[Enric Balletbo i Serra <enric.balletbo@collabora.com>]

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