On 10.11.20 18:04, Cristian Marussi wrote: > Hi Peter > > thanks for the review. > > On Tue, Nov 10, 2020 at 05:01:26PM +0100, Peter Hilber wrote: >> On 26.10.20 21:10, Cristian Marussi wrote: >>> Add new .reading_get_timestamped() method to sensor_ops to support SCMIv3.0 >>> timestamped reads. >>> >>> Signed-off-by: Cristian Marussi <cristian.maru...@arm.com> >>> --- >>> drivers/firmware/arm_scmi/sensors.c | 134 ++++++++++++++++++++++++++-- >>> include/linux/scmi_protocol.h | 22 +++++ >>> 2 files changed, 151 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/firmware/arm_scmi/sensors.c >>> b/drivers/firmware/arm_scmi/sensors.c >>> index 5a18f8c84bef..bdb0ed0df683 100644 >>> --- a/drivers/firmware/arm_scmi/sensors.c >>> +++ b/drivers/firmware/arm_scmi/sensors.c >>> @@ -156,6 +156,27 @@ struct scmi_msg_sensor_reading_get { >>> #define SENSOR_READ_ASYNC BIT(0) >>> }; >>> >>> +struct scmi_resp_sensor_reading_get { >>> + __le64 readings; >>> +}; >>> + >>> +struct scmi_resp_sensor_reading_complete { >>> + __le32 id; >>> + __le64 readings; >>> +}; >> >> In my understanding the id field is not present in the spec. The >> implementation seems to have introduced it already before this patch. >> > > Well, it is indeed defined in 4.7.3.1 "SENSOR_READING_COMPLETE" both in > SCMI V3.0 and in V2.0: it is the async delayed response and this 'id' > represents the sensor_id: in fact it is used only the in the async path > in the reading funcs; the sync version uses directly sensor_reading_le. > (which has no id n it)
You are right, sorry for the noise. >>> +/** >>> + * scmi_sensor_reading_get - Read scalar sensor value >>> + * @handle: Platform handle >>> + * @sensor_id: Sensor ID >>> + * @value: The 64bit value sensor reading >>> + * >>> + * This function returns a single 64 bit reading value representing the >>> sensor >>> + * value; if the platform SCMI Protocol implementation and the sensor >>> support >>> + * multiple axis and timestamped-reads, this just returns the first axis >>> while >>> + * dropping the timestamp value. >>> + * Use instead the @scmi_sensor_reading_get_timestamped to retrieve the >>> array of >>> + * timestamped multi-axis values. >>> + * >>> + * Return: 0 on Success >>> + */ >>> static int scmi_sensor_reading_get(const struct scmi_handle *handle, >>> u32 sensor_id, u64 *value) >>> { >>> @@ -593,18 +629,105 @@ static int scmi_sensor_reading_get(const struct >>> scmi_handle *handle, >> >> How about changing the scmi_xfer_get_init() rx_size to 0 (in the >> immediately preceding, not shown lines)? An SCMI platform might not >> expect to just have room for the first reading, excluding the timestamp. >> > > Ah right, because this is the old v2.0 interface which I kept unchanged but > now internally the same v3.0 SENSOR_READING_GET message on a v3.0 platform > could return multiple per-axis timestamped values even if I just return > the first u64 without timestamp. Is this that you mean ? Yes. Best regards, Peter