On Sat, Mar 28, 2020 at 10:22 AM Jonathan Cameron <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 27 Mar 2020 15:34:43 -0700 > Gwendal Grignou <gwendal@xxxxxxxxxxxx> wrote: > > > Add buffer/hwfifo_flush. It is not part of the ABI, but it follows ST > > and HID lead: Tells the sensor hub to send to the host all pending > > sensor events. > > > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx> > > Unless I'm missing something there aren't any other drivers providing > an explicit flush attribute. The flush attribute comes from a requirement from Android to ask the sensorhub to flush the samples still in its FIFO queue. (see https://source.android.com/devices/sensors/hal-interface#flush_sensor) It has been implemented in the ST Android HAL, which expects a hw_fifo_flush attribute.: https://github.com/STMicroelectronics/STMems_Android_Sensor_HAL_IIO/blob/STMems_Android_Sensor_HAL_IIO/src/utils.cpp#L31 But I misread kernel ST code; as you said, the request to flush appends only when the buffer is enabled/disabled or the sensor suspended, it is not exposed to user space. For Bosh sensor : there is a patch that was proposed a while back: "http://lkml.iu.edu/hypermail/linux/kernel/1504.3/03270.html";, but it never reached mainline. For HID, the attribute is defined in the HID specification (31C) : https://www.usb.org/sites/default/files/hutrr59_-_usages_for_wearables_0.pdf but I could not find a publicly available proposed change request that uses it. Anyhow, it was a mistake to put this patch in the current patch set. I need it on chromebook for supporting Android, but it should be discussed more widely to have it part of the ABI, or define a better solution. > The nearest equivalent is the flush > callback which reads out stuff that is in a fifo to be read, but which > hasn't yet reached a watermark to trigger normal readback. > > Can we do something similar here? > > If not this needs ABI documentation in Documentation/ABI/testing/... > I'm not keen on it in becoming general ABI unless I'm missing a > strong argument in favour of it. > > Jonathan Thank you for your support, Gwendal. > > > > --- > > No changes in v7. > > New in v6. > > > > .../cros_ec_sensors/cros_ec_sensors_core.c | 28 +++++++++++++++++++ > > 1 file changed, 28 insertions(+) > > > > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > > index c831915ca7e56..aaf124a82e0e4 100644 > > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > > @@ -113,6 +113,33 @@ static int cros_ec_sensor_set_ec_rate(struct cros_ec_sensors_core_state *st, > > return ret; > > } > > > > +static ssize_t cros_ec_sensors_flush(struct device *dev, > > + struct device_attribute *attr, > > + const char *buf, size_t len) > > +{ > > + struct iio_dev *indio_dev = dev_to_iio_dev(dev); > > + struct cros_ec_sensors_core_state *st = iio_priv(indio_dev); > > + int ret = 0; > > + bool flush; > > + > > + ret = strtobool(buf, &flush); > > + if (ret < 0) > > + return ret; > > + if (!flush) > > + return -EINVAL; > > + > > + mutex_lock(&st->cmd_lock); > > + st->param.cmd = MOTIONSENSE_CMD_FIFO_FLUSH; > > + ret = cros_ec_motion_send_host_cmd(st, 0); > > + if (ret != 0) > > + dev_warn(&indio_dev->dev, "Unable to flush sensor\n"); > > + mutex_unlock(&st->cmd_lock); > > + return ret ? ret : len; > > +} > > + > > +static IIO_DEVICE_ATTR(hwfifo_flush, 0644, NULL, > > + cros_ec_sensors_flush, 0); > > + > > static ssize_t cros_ec_sensor_set_report_latency(struct device *dev, > > struct device_attribute *attr, > > const char *buf, size_t len) > > @@ -175,6 +202,7 @@ static ssize_t hwfifo_watermark_max_show(struct device *dev, > > static IIO_DEVICE_ATTR_RO(hwfifo_watermark_max, 0); > > > > const struct attribute *cros_ec_sensor_fifo_attributes[] = { > > + &iio_dev_attr_hwfifo_flush.dev_attr.attr, > > &iio_dev_attr_hwfifo_timeout.dev_attr.attr, > > &iio_dev_attr_hwfifo_watermark_max.dev_attr.attr, > > NULL, >
