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 class
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
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
>>>> --
>>>
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
>
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:
>>>>
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
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:
>>>>
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 not.
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 wi
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:
>
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 lo
er. Drop
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
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
---
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
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
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
On 15.06.24 10:01, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>>
>> + ret = viortc_hw_xtstamp_params(&hw_counter, &cs_id);
>> + if (ret)
>> + return ret;
>> +
>> + kt
Changing virtio-dev address to the new one.
On 15.06.24 09:50, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>>
>> +int viortc_hw_xtstamp_params(u16 *hw_counter, enum clocksource_ids *cs_id)
>> +{
>> + *hw_counter = VIRTIO_RTC_COU
Changing virtio-dev address to the new one. The discussion might also be
relevant for virtio-comment, but it is discouraged to forward it to both.
On 15.06.24 10:40, David Woodhouse wrote:
> On Mon, 2023-12-18 at 08:38 +0100, Peter Hilber wrote:
>> RFC v3 updates
>> --
On 21.06.24 10:45, David Woodhouse wrote:
> On Thu, 2024-06-20 at 17:19 +0100, David Woodhouse wrote:
>>
>>>
+
+ /* Counter frequency, and error margin. Units of (second >> 64) */
+ uint64_t counter_period_frac_sec;
>>>
>>> AFAIU this might limit the precision in case of
On 25.06.24 21:01, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based cross timestamps into
>
On 27.06.24 16:52, David Woodhouse wrote:
> On Thu, 2024-06-27 at 15:50 +0200, Peter Hilber wrote:
>> On 25.06.24 21:01, David Woodhouse wrote:
>>> From: David Woodhouse
>>>
>>> The vmclock "device" provides a shared memory region with precision clo
On 27.06.24 18:03, David Woodhouse wrote:
>
> I've updated the tree at
> https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/vmclock
> (but not yet the qemu one).
>
> I think I've taken into account all your comments apart from the one
> about non-64-bit counters wrapping. I reduc
On 28.06.24 14:15, David Woodhouse wrote:
> On Fri, 2024-06-28 at 13:33 +0200, Peter Hilber wrote:
>> On 27.06.24 16:52, David Woodhouse wrote:
>>> I already added a flags field, so this might look something like:
>>>
>>> /*
>>> * Smear
On 01.07.24 10:57, David Woodhouse wrote:
> On Fri, 2024-06-28 at 22:27 +0100, David Woodhouse wrote:
>> On 28 June 2024 17:38:15 BST, Peter Hilber
>> wrote:
>>> On 28.06.24 14:15, David Woodhouse wrote:
>>>> On Fri, 2024-06-28 at 13:33 +0200, Peter Hilber w
On 02.07.24 18:39, David Woodhouse wrote:
> On Tue, 2024-07-02 at 17:03 +0200, Peter Hilber wrote:
>>> On 01.07.24 10:57, David Woodhouse wrote:
>>>>> If my proposed memory structure is subsumed into the virtio-rtc
>>>>> proposal we'd literally
On 02.07.24 20:40, David Woodhouse wrote:
> On 2 July 2024 19:12:00 BST, Peter Hilber
> wrote:
>> On 02.07.24 18:39, David Woodhouse wrote:
>>> To clarify then, the main types are
>>>
>>> VIRTIO_RTC_CLOCK_UTC == 0
>>> VIRTIO_RTC_CLO
On 03.07.24 12:40, David Woodhouse wrote:
[...]
>
>
> This is what I currently have for 'struct vmclock_abi' that I'd like to
> persuade you to adopt. I need to tweak it some more, for at least the
> following reasons, as well as any more you can see:
>
> • size isn't big enough for 64KiB pag
On 05.07.24 17:02, David Woodhouse wrote:
> On Fri, 2024-07-05 at 10:12 +0200, Peter Hilber wrote:
>> On 03.07.24 12:40, David Woodhouse wrote:
[...]
>>> • Why is maxerror in picoseconds? It's the only use of that unit
>
> Between us we now have picoseconds, nan
On 08.07.24 11:27, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based cross timestamps into
>
On 10.07.24 18:01, David Woodhouse wrote:
> On Wed, 2024-07-10 at 15:07 +0200, Peter Hilber wrote:
>> On 08.07.24 11:27, David Woodhouse wrote:
>>> From: David Woodhouse
>>>
>>> The vmclock "device" provides a shared memory region with precision clo
On 11.07.24 09:50, David Woodhouse wrote:
> On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
>>
>> IMHO this phrasing is better, since it directly refers to the state of the
>> structure.
>
> Thanks. I'll update it.
>
>> AFAIU if there would be
On 08.07.24 11:27, David Woodhouse wrote:
> +
> + /*
> + * Time according to time_type field above.
> + */
> + uint64_t time_sec; /* Seconds since time_type epoch */
> + uint64_t time_frac_sec; /* (seconds >> 64) */
> + uint64_t time_esterror_picosec;
On 16.07.24 14:32, David Woodhouse wrote:
> On 16 July 2024 12:54:52 BST, Peter Hilber
> wrote:
>> On 11.07.24 09:50, David Woodhouse wrote:
>>> On Thu, 2024-07-11 at 09:25 +0200, Peter Hilber wrote:
>>>>
>>>> IMHO this phrasing is better,
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
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 scmi_iio_get_chan_modifier(
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 lo
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
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 inserti
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
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
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
ond RFC state. Please 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
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-by
mware: arm_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
fir
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
-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
/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
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
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
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
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
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
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
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 prob
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
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
-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
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
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
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-by
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
62 matches
Mail list logo
