Re: [RFC PATCH 6/7] dt-bindings: arm: Add virtio transport for SCMI

2020-10-02 Thread Peter Hilber
On 23.09.20 22:54, Rob Herring wrote: > On Fri, Sep 18, 2020 at 06:55:58PM +0200, Peter Hilber wrote: >> From: Igor Skalkin >> >> Document the properties for arm,scmi-virtio compatible nodes. The >> backing virtio SCMI device is described in patch [1]. >> &g

Re: [RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport

2020-11-12 Thread Peter Hilber
ase see individual responses below. Best regards, Peter > > > On Thu, Nov 05, 2020 at 10:21:16PM +0100, Peter Hilber wrote: >> From: Igor Skalkin >> >> This transport enables accessing an SCMI platform as a virtio device. >> >> Implement an SCMI virtio driver

Re: [PATCH v2 6/6] firmware: arm_scmi: add SCMIv3.0 Sensor notifications

2020-11-10 Thread Peter Hilber
On 26.10.20 21:10, Cristian Marussi wrote: > Add support for new SCMIv3.0 SENSOR_UPDATE notification. > > Signed-off-by: Cristian Marussi > --- > drivers/firmware/arm_scmi/sensors.c | 124 > include/linux/scmi_protocol.h | 9 ++ > 2 files changed, 116

Re: [PATCH v2 4/6] firmware: arm_scmi: add SCMIv3.0 Sensors timestamped reads

2020-11-10 Thread Peter Hilber
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 > --- > drivers/firmware/arm_scmi/sensors.c | 134 ++-- > include/linux/scmi_protocol.h

Re: [PATCH v2 4/6] firmware: arm_scmi: add SCMIv3.0 Sensors timestamped reads

2020-11-10 Thread Peter Hilber
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

Re: [PATCH v2 2/6] firmware: arm_scmi: add SCMIv3.0 Sensors descriptors extensions

2020-11-10 Thread Peter Hilber
Hi Cristian, sorry, I mistakenly used the wrong sender ("Mailing Lists") for the original comment mail. Please see below for my reply. On 10.11.20 18:21, Cristian Marussi wrote: > On Tue, Nov 10, 2020 at 05:00:05PM +0100, Mailing Lists wrote: >> On 26.10.20 21:10, Cristian Marussi wrote: >>> Add

[RFC PATCH v2 09/10] dt-bindings: arm: Add virtio transport for SCMI

2020-11-05 Thread Peter Hilber
From: Igor Skalkin Document the properties for arm,scmi-virtio compatible nodes. The backing virtio SCMI device is described in patch [1]. [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off

[RFC PATCH v2 00/10] firmware: arm_scmi: Add virtio transport

2020-11-05 Thread Peter Hilber
_scmi: Add xfer_init_buffers transport op dt-bindings: arm: Add virtio transport for SCMI firmware: arm_scmi: Add virtio transport Peter Hilber (3): firmware: arm_scmi: Add optional link_supplier() transport op firmware: arm_scmi: Add per-device transport private info firmware: arm

[RFC PATCH v2 02/10] firmware: arm_scmi: Document that max_msg is a per channel type limit

2020-11-05 Thread Peter Hilber
Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h index aed192238177..38e6aabbe3dd 100644 --- a/drivers

[RFC PATCH v2 03/10] firmware: arm_scmi: Add op to override max message #

2020-11-05 Thread Peter Hilber
-virtio can report the actual max message # for each channel type. Respect these new limits. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 8 - drivers/firmware/arm_scmi/driver.c | 49

[RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport

2020-11-05 Thread Peter Hilber
/ballot.php?id=3496 Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- MAINTAINERS| 1 + drivers/firmware/Kconfig | 12 +- drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/common.h | 14 + drivers

[RFC PATCH v2 04/10] firmware: arm_scmi: Add per message transport data

2020-11-05 Thread Peter Hilber
virtqueues, the tx and rx buffers should not overlap. The first step to solve the aforementioned issues is to add a transport-specific data pointer to scmi_xfer. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 2

[RFC PATCH v2 08/10] firmware: arm_scmi: Add is_scmi_protocol_device()

2020-11-05 Thread Peter Hilber
The scmi-virtio transport driver will need to distinguish SCMI protocol devices from the SCMI instance device in the chan_setup() and chan_free() ops. Add this internal helper to be able to distinguish the two. Signed-off-by: Peter Hilber --- drivers/firmware/arm_scmi/bus.c| 5

[RFC PATCH v2 07/10] firmware: arm_scmi: Add per-device transport private info

2020-11-05 Thread Peter Hilber
driver_data.) Signed-off-by: Peter Hilber --- drivers/firmware/arm_scmi/common.h | 2 ++ drivers/firmware/arm_scmi/driver.c | 35 ++ 2 files changed, 37 insertions(+) diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h index

[RFC PATCH v2 06/10] firmware: arm_scmi: Add optional link_supplier() transport op

2020-11-05 Thread Peter Hilber
For the scmi-virtio transport, it might not be possible to refer to the proper virtio device at device tree build time. Therefore, add an op which will allow scmi-virtio to dynamically link to the proper virtio device during probe. Signed-off-by: Peter Hilber --- drivers/firmware/arm_scmi

[RFC PATCH v2 01/10] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional

2020-11-05 Thread Peter Hilber
dependency of SCMI on mailbox. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/Kconfig | 9 - drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/common.h | 2 ++ drivers/firmware/arm_scmi/driver.c | 2

[RFC PATCH v2 05/10] firmware: arm_scmi: Add xfer_init_buffers transport op

2020-11-05 Thread Peter Hilber
for the prepended transport-specific headers. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 3 +++ drivers/firmware/arm_scmi/driver.c | 21 +++-- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git

[RFC PATCH 0/7] firmware: arm_scmi: Add virtio transport

2020-09-18 Thread Peter Hilber
This series implements an SCMI virtio driver according to the virtio SCMI device spec patch v5 [1], after simple preparatory changes to the existing arm-scmi driver. The virtio transport differs in some respects from the existing shared-memory based SCMI transports. Message timeouts can be a

[RFC PATCH 1/7] firmware: arm_scmi, smccc, mailbox: Make shmem based transports optional

2020-09-18 Thread Peter Hilber
dependency of SCMI on mailbox. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/Kconfig | 9 - drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/common.h | 2 ++ drivers/firmware/arm_scmi/driver.c | 2

[RFC PATCH 2/7] firmware: arm_scmi: Document that max_msg is a per channel type limit

2020-09-18 Thread Peter Hilber
Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h index 36c38334a045..4cc78eb27f14 100644 --- a/drivers

[RFC PATCH 3/7] firmware: arm_scmi: Add op to override max message #

2020-09-18 Thread Peter Hilber
-virtio can report the actual max message # for each channel type. Respect these new limits. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 8 - drivers/firmware/arm_scmi/driver.c | 49

[RFC PATCH 4/7] firmware: arm_scmi: Add per message transport data

2020-09-18 Thread Peter Hilber
virtqueues, the tx and rx buffers should not overlap. The first step to solve the aforementioned issues is to add a transport-specific data pointer to scmi_xfer. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 2

[RFC PATCH 5/7] firmware: arm_scmi: Add xfer_init_buffers transport op

2020-09-18 Thread Peter Hilber
for the prepended transport-specific headers. Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- drivers/firmware/arm_scmi/common.h | 3 +++ drivers/firmware/arm_scmi/driver.c | 21 +++-- 2 files changed, 18 insertions(+), 6 deletions(-) diff --git

[RFC PATCH 6/7] dt-bindings: arm: Add virtio transport for SCMI

2020-09-18 Thread Peter Hilber
From: Igor Skalkin Document the properties for arm,scmi-virtio compatible nodes. The backing virtio SCMI device is described in patch [1]. [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off

[RFC PATCH 7/7] firmware: arm_scmi: Add virtio transport

2020-09-18 Thread Peter Hilber
probe failure or remove. [1] https://lists.oasis-open.org/archives/virtio-comment/202005/msg00096.html [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Co-developed-by: Peter Hilber Signed-off-by: Peter Hilber Signed-off-by: Igor Skalkin --- MAINTAINERS| 1

Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

2021-01-26 Thread Peter Hilber
On 22.01.21 00:21, Jyoti Bhayana wrote: > + > +static int scmi_iio_get_sensor_max_range(struct iio_dev *iio_dev, int *val, > + int *val2) > +{ > + struct scmi_iio_priv *sensor = iio_priv(iio_dev); > + int max_range_high, max_range_low; > + long

Re: [PATCH v7 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

2021-03-10 Thread Peter Hilber
On 10.03.21 00:12, Jyoti Bhayana wrote: > This change provides ARM SCMI Protocol based IIO device. > This driver provides support for Accelerometer and Gyroscope using > SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification > [snip] > + > +static int

Re: [PATCH v7 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

2021-03-11 Thread Peter Hilber
e implementation only would in principle be possible (disregarding integration timeline constraints). Best regards, Peter > Thanks, > Jyoti > > On Wed, Mar 10, 2021 at 3:16 AM Peter Hilber > wrote: >> >> On 10.03.21 00:12, Jyoti Bhayana wrote: >>> This change provide

[RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2023-12-17 Thread Peter Hilber
rop arm_arch_timer helper functions (Marc Zyngier). - Improve cross-timestamp fixes problem description and implementation (John Stultz). Peter Hilber (7): timekeeping: Fix cross-timestamp interpolation on counter wrap timekeeping: Fix cross-timestamp interpolation corner case deci

[RFC PATCH v3 5/7] virtio_rtc: Add PTP clocks

2023-12-17 Thread Peter Hilber
irtio_rtc should in the future also expose clocks as RTC class devices, do not have VIRTIO_RTC depend on PTP_1588_CLOCK. Signed-off-by: Peter Hilber --- Notes: v3: - don't guard cross-timestamping with feature bit (spec v3) - reduce clock id to 16 bits (spec v3) v2:

[RFC PATCH v3 4/7] virtio_rtc: Add module and driver core

2023-12-17 Thread Peter Hilber
patch will expose PTP clocks. Provide synchronous messaging, which is enough for the expected time synchronization use cases through PTP clocks (similar to ptp_kvm) or RTC Class driver. Signed-off-by: Peter Hilber --- Notes: v3: - merge readq and controlq into a single requestq (spec

[RFC PATCH v3 6/7] virtio_rtc: Add Arm Generic Timer cross-timestamping

2023-12-17 Thread Peter Hilber
Add PTP_SYS_OFFSET_PRECISE2 support on platforms using the Arm Generic Timer. Always report the CP15 virtual counter as the HW counter in use by arm_arch_timer, since the Linux kernel's usage of the Arm Generic Timer should always be compatible with this. Signed-off-by: Peter Hilber --- Notes

[RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver

2023-12-17 Thread Peter Hilber
in case it was a CLOCK_BOOTTIME_ALARM alarm. Otherwise, the behavior should not differ from other RTC class drivers. Signed-off-by: Peter Hilber --- Notes: Added in v3. drivers/virtio/Kconfig | 21 +- drivers/virtio/Makefile | 1 + drivers/virtio

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-08 Thread Peter Hilber
On 07.03.24 15:02, David Woodhouse wrote: > On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote: >> RFC v3 updates >> -- >> >> This series implements a driver for a virtio-rtc device conforming to spec >> RFC v3 [1]. It now includes an RTC cla

Re: [RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver

2024-03-11 Thread Peter Hilber
On 08.03.24 18:03, Alexandre Belloni wrote: > Hello, > > I'll start by saying that I'm sorry, I have a very very high level > knowledge about what virtio is. > > On 18/12/2023 08:38:45+0100, Peter Hilber wrote: >> Expose the virtio-rtc UTC clock as an RTC clock to usersp

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-11 Thread Peter Hilber
On 08.03.24 13:33, David Woodhouse wrote: > On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote: >> On 07.03.24 15:02, David Woodhouse wrote: >>> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote: >>>> RFC v3 updates >>>> -- >>>

Re: [RFC PATCH v3 7/7] virtio_rtc: Add RTC class driver

2024-03-13 Thread Peter Hilber
On 11.03.24 20:46, Alexandre Belloni wrote: > On 11/03/2024 19:28:50+0100, Peter Hilber wrote: >>>> Perhaps this might be handled by the driver also setting a virtio-rtc >>>> monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). >>>> The >

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-13 Thread Peter Hilber
On 12.03.24 18:15, David Woodhouse wrote: > On Mon, 2024-03-11 at 19:24 +0100, Peter Hilber wrote: >> On 08.03.24 13:33, David Woodhouse wrote: >>> On Fri, 2024-03-08 at 11:32 +0100, Peter Hilber wrote: >>>> On 07.03.24 15:02, David Woodhouse wrote: >>>>

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-14 Thread Peter Hilber
Now CC'ing the previous commenters to the virtio-rtc spec draft, since this discussion is mostly about the spec, and the Virtio mailing lists still seem to be in a migration hiatus... On 13.03.24 19:18, David Woodhouse wrote: > On 13 March 2024 17:50:48 GMT, Peter Hilber > wrote: >>

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-14 Thread Peter Hilber
On 13.03.24 21:12, Andrew Lunn wrote: >> As long as it doesn't behave differently from the other RTC, I'm fine >> with this. This is important because I don't want to carry any special >> infrastructure for this driver or to have to special case this driver >> later on because it is incompatible

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-13 Thread Peter Hilber
On 13.03.24 12:18, Alexandre Belloni wrote: > On 13/03/2024 10:45:54+0100, Peter Hilber wrote: >>> Exposing UTC as the only clock reference is bad enough; when leap >>> seconds happen there's a whole second during which you don't *know* >>> which second it is. It se

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-19 Thread Peter Hilber
While the virtio-comment list is not available, now also CC'ing Parav, which may be interested in this virtio-rtc spec related discussion thread. On 14.03.24 15:19, David Woodhouse wrote: > On 14 March 2024 11:13:37 CET, Peter Hilber > wrote: >>> To a certain extent, as long as

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-13 Thread Peter Hilber
On 13.03.24 13:45, David Woodhouse wrote: > On Wed, 2024-03-13 at 10:45 +0100, Peter Hilber wrote: >> On 12.03.24 18:15, David Woodhouse wrote: >>> On Mon, 2024-03-11 at 19:24 +0100, Peter Hilber wrote: >>>> On 08.03.24 13:33, David Woodhouse wrote: >>>>

Re: [RFC PATCH v3 0/7] Add virtio_rtc module and related changes

2024-03-13 Thread Peter Hilber
On 13.03.24 15:06, David Woodhouse wrote: > On Wed, 2024-03-13 at 13:58 +0100, Alexandre Belloni wrote: >> The TSC or whatever CPU counter/clock that is used to keep the system >> time is not an RTC, I don't get why it has to be exposed as such to the >> guests. PTP is fine and precise, RTC is