ce_system_crosststamp().
As a fallback, support the ioctl PTP_SYS_OFFSET_EXTENDED2 for all
platforms.
Assume that concurrency issues during PTP clock removal are avoided by the
posix_clock framework.
Kconfig recursive dependencies prevent virtio_rtc from implicitly enabling
PTP_1588_CLOCK, theref
patches will expose PTP clocks and an RTC Class device.
Provide synchronous messaging, which is enough for the expected time
synchronization use cases through PTP clocks (similar to ptp_kvm) or RTC
Class device.
Signed-off-by: Peter Hilber
---
Notes:
v6:
- Fix sparse warning about
setting a virtio-rtc
monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). The
virtio-rtc monotonic alarm would just be used to wake up 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
Acked
For platforms using the Arm Generic Timer, add precise cross-timestamping
support to virtio_rtc.
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:
with get_device_system_crosststamp().
- Assume Arm Generic Timer will use CP15 virtual counter. Drop
arm_arch_timer helper functions (Marc Zyngier).
- Improve cross-timestamp fixes problem description and implementation
(John Stultz).
Peter Hilber (4):
virtio_rtc: Add module and driver core
On Tue, Mar 18, 2025 at 10:04:07AM +0800, Lei Yang wrote:
> QE tested this series of patches v6 with virtio-net regression tests,
> everything works fine.
>
> Tested-by: Lei Yang
>
Hi Lei,
thanks for the reply! However, I am not sure which virtio-net regression
tests you are referring to, and
ce_system_crosststamp().
As a fallback, support the ioctl PTP_SYS_OFFSET_EXTENDED2 for all
platforms.
Assume that concurrency issues during PTP clock removal are avoided by the
posix_clock framework.
Kconfig recursive dependencies prevent virtio_rtc from implicitly enabling
PTP_1588_CLOCK, theref
setting a virtio-rtc
monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). The
virtio-rtc monotonic alarm would just be used to wake up 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
Acked
For platforms using the Arm Generic Timer, add precise cross-timestamping
support to virtio_rtc.
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:
patches will expose PTP clocks and an RTC Class device.
Provide synchronous messaging, which is enough for the expected time
synchronization use cases through PTP clocks (similar to ptp_kvm) or RTC
Class device.
Signed-off-by: Peter Hilber
---
Notes:
v6:
- Fix sparse warning about
_arch_timer helper functions (Marc Zyngier).
- Improve cross-timestamp fixes problem description and implementation
(John Stultz).
Peter Hilber (4):
virtio_rtc: Add module and driver core
virtio_rtc: Add PTP clocks
virtio_rtc: Add Arm Generic Timer cross-timestamping
virtio_rtc: Add RTC clas
On Tue, Feb 25, 2025 at 07:18:59AM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 19, 2025 at 08:32:55PM +0100, Peter Hilber wrote:
> > This series implements a driver for a virtio-rtc device conforming to spec
> > proposal v7 [1]. It includes a PTP clock driver and an RTC class
On Mon, Feb 24, 2025 at 05:55:27PM +, Simon Horman wrote:
> On Wed, Feb 19, 2025 at 08:32:56PM +0100, Peter Hilber wrote:
>
> ...
>
> > +/**
> > + * VIORTC_MSG() - extract message from message handle
> > + * @hdl: message handle
> > + *
> > + * Retur
On Mon, Feb 24, 2025 at 05:56:18PM +, Simon Horman wrote:
> On Wed, Feb 19, 2025 at 08:32:57PM +0100, Peter Hilber wrote:
>
> ...
>
> > +/**
> > + * viortc_ptp_gettimex64() - PTP clock gettimex64 op
> > + *
>
> Hi Peter,
>
> Tooling recognises
source id for
get_device_system_crosststamp()" to avoid requiring a clocksource pointer
with get_device_system_crosststamp().
- Assume Arm Generic Timer will use CP15 virtual counter. Drop
arm_arch_timer helper functions (Marc Zyngier).
- Improve cross-timestamp fixes problem description and implementatio
_CLOCK, therefore just warn the user if PTP_1588_CLOCK is not
available. Since virtio_rtc should in the future also expose clocks as RTC
class devices, do not depend VIRTIO_RTC on PTP_1588_CLOCK.
Signed-off-by: Peter Hilber
---
Notes:
v5:
- Fix style issues.
v4:
setting a virtio-rtc
monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). The
virtio-rtc monotonic alarm would just be used to wake up 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
Acked
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
---
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:
v5:
- Remove definitions dropped in virtio-rtc spec v7
On Thu, Jan 02, 2025 at 08:21:11AM -0800, Richard Cochran wrote:
> On Thu, Jan 02, 2025 at 05:11:01PM +0100, Peter Hilber wrote:
> > For sure. But the aim of this proposal is to have an interoperable time
> > synchronization solution for VMs through a Virtio device. So the idea is
On Wed, Dec 25, 2024 at 04:42:14PM -0800, Richard Cochran wrote:
> On Mon, Dec 23, 2024 at 07:13:46PM +0100, Peter Hilber wrote:
>
> > The precise synchronization of the VM guest with its immediate
> > environment can also be important; a VM guest may depend the decision
>
On Fri, Dec 20, 2024 at 07:19:52AM -0800, Richard Cochran wrote:
> On Thu, Dec 19, 2024 at 09:42:03PM +0100, Peter Hilber wrote:
> > Ioctl PTP_SYS_OFFSET_PRECISE2 provides cross-timestamping of device time
> > and system time. This can be used for virtualization where (virtualizatio
: Peter Hilber
---
drivers/virtio/Kconfig | 4 +-
drivers/virtio/virtio_rtc_driver.c | 122 ++-
drivers/virtio/virtio_rtc_internal.h | 3 +-
drivers/virtio/virtio_rtc_ptp.c | 25 +++---
4 files changed, 140 insertions(+), 14 deletions(-)
diff --git a
nd to race conditions.
TBD
===
- Dissect new ioctl flags in testptp.
[1]
https://lore.kernel.org/virtio-comment/20241206094819.858-1-quic_phil...@quicinc.com/T/#t
[2] cf. struct vmclock_abi in
https://lore.kernel.org/all/78969a39b51ec00e85551b752767be65f6794b46.ca...@infradead.org/
Signed-off
ned-off-by: Peter Hilber
Peter Hilber (2):
ptp: add PTP_SYS_OFFSET_STAT for xtstamping with status
virtio_rtc: Support PTP_SYS_OFFSET_STAT ioctl
drivers/ptp/ptp_chardev.c | 39
drivers/ptp/ptp_clock.c | 9 ++
drivers/virtio/Kconfig| 4 +
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
---
setting a virtio-rtc
monotonic alarm (which uses a clock similar to CLOCK_BOOTTIME_ALARM). The
virtio-rtc monotonic alarm would just be used to wake up 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
_CLOCK, therefore just warn the user if PTP_1588_CLOCK is not
available. Since virtio_rtc should in the future also expose clocks as RTC
class devices, do not depend VIRTIO_RTC on PTP_1588_CLOCK.
Signed-off-by: Peter Hilber
---
Notes:
v4:
- Distinguish UTC-like clocks by han
amp()" to avoid requiring a clocksource pointer
with get_device_system_crosststamp().
- Assume Arm Generic Timer will use CP15 virtual counter. Drop
arm_arch_timer helper functions (Marc Zyngier).
- Improve cross-timestamp fixes problem description and implementation
(John Stultz).
Pet
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:
v4:
- Update Virtio interface to spec v6
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,
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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
>> --
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
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
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
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:
>
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
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 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 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 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 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 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 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 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
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
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
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
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
---
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
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
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
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
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
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
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
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
/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
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
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
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
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
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
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
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
-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
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
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
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
92 matches
Mail list logo
