Message ID | 20220217131234.50328-1-cristian.marussi@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Add SCMI Virtio & Clock atomic support | expand |
On Thu, 17 Feb 2022 13:12:26 +0000, Cristian Marussi wrote: > This small series is the tail-subset of the previous V8 series about atomic > support in SCMI [1], whose 8-patches head-subset has now been queued on > [2]; as such, it is based on [2] on top of tag scmi-updates-5.17: > > commit 94d0cd1da14a ("firmware: arm_scmi: Add new parameter to > mark_txdone") > > [...] Applied to sudeep.holla/linux (for-next/scmi/updates), thanks! [1/8] firmware: arm_scmi: Add a virtio channel refcount https://git.kernel.org/sudeep.holla/c/42e90eb53b [2/8] firmware: arm_scmi: Review virtio free_list handling https://git.kernel.org/sudeep.holla/c/9a1699bda0 [3/8] firmware: arm_scmi: Add atomic mode support to virtio transport https://git.kernel.org/sudeep.holla/c/5a3b7185c4 [4/8] dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional property https://git.kernel.org/sudeep.holla/c/0539884ccc [5/8] firmware: arm_scmi: Support optional system wide atomic-threshold-us https://git.kernel.org/sudeep.holla/c/05976c5f3b [6/8] firmware: arm_scmi: Add atomic support to clock protocol https://git.kernel.org/sudeep.holla/c/b7bd36f2e9 [7/8] firmware: arm_scmi: Add support for clock_enable_latency https://git.kernel.org/sudeep.holla/c/18f295b758 [8/8] clk: scmi: Support atomic clock enable/disable API https://git.kernel.org/sudeep.holla/c/38a0e5b735 -- Regards, Sudeep
On Thu, Feb 17, 2022 at 01:12:26PM +0000, Cristian Marussi wrote: > Hi, > > This small series is the tail-subset of the previous V8 series about atomic > support in SCMI [1], whose 8-patches head-subset has now been queued on > [2]; as such, it is based on [2] on top of tag scmi-updates-5.17: > > commit 94d0cd1da14a ("firmware: arm_scmi: Add new parameter to > mark_txdone") > > Patch [1/8] substitute virtio-scmi ready flag and lock with a reference > counter to keep track of vio channels lifetime while removing the need of > a wide spinlocked section (that would cause issues with introduction of > virtio polling support) > > Patch [2/8] adds a few helpers to handle the TX free_list and a dedicated > spinlock to reduce the reliance on the main one. > > Patch [3/8] adds polling mode to SCMI VirtIO transport in order to support > atomic operations on such transport. > > Patches [4,5/8] introduce a new optional SCMI binding, atomic-threshold-us, > to configure a platform specific time threshold used in the following > patches to select with a finer grain which SCMI resources should be > eligible for atomic operations when requested. > > Patch [6/8] exposes new SCMI Clock protocol operations to allow an SCMI > user to request atomic mode on clock enable commands. > > Patch [7/8] adds support to SCMI Clock protocol for a new clock attributes > field which advertises typical enable latency for a specific resource. > > Finally patch [8/8] add support for atomic operations to the SCMI clock > driver; the underlying logic here is that we register with the Clock > framework atomic-capable clock resources if and only if the backing SCMI > transport is capable of atomic operations AND the specific clock resource > has been advertised by the SCMI platform as having: > > clock_enable_latency <= atomic-threshold-us > > The idea is to avoid costly atomic busy-waiting for resources that have > been advertised as 'slow' to operate upon. (i.e. a PLL vs a gating clock) > > To ease testing the whole series can be find at [3]. > > Any feedback/testing welcome as usual. > > Thanks, > Cristian SCMI specific stuff so I don't have anything to add here. By the way, it does not look like anything regarding SCMI atomic support is needed in the virtio spec - is it true the interface with the device is unaffected? > [1]: https://lore.kernel.org/linux-arm-kernel/20211220195646.44498-1-cristian.marussi@arm.com/ > [2]: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/tag/?h=scmi-updates-5.17 > [3]: https://gitlab.arm.com/linux-arm/linux-cm/-/commits/scmi_atomic_clk_virtio_V5/ > > --- > v4 --> v5 > - dt_bindings: fixed example and removed dtschema warnings/errors > - dt_bindings: added 'default: 0' clause > - introduced vio_msg refcounts and helpers to avoid premature reuse of > freed messages when both poling and IRQ path are active on a buffer > - better handling of timed out polled messages on late replies using > new VIO_MSG_POLL_TIMEOUT state > - fixed comments on locks > - removed unneeded virtqueue re-enable when fail to acquire channel in > complete_cb > > V3 --> V4 > - renamed optional DT property to atomic-threshold-us > > V2 --> V3 > - split out virtio_ring RFC patch into a distinct series > - calling virtqueue_broke_device when cleaning up channel > - removed RFC tags from CLK related patches > > V1 --> V2 > - added vio channel refcount support patch > - reviewed free_list support and usage > - added virtio_ring RFC patch > - shrinked spinlocked section within virtio_poll_done to exclude > virtqueue_poll call > - removed poll_lock > - use vio channel refcount acquire/release logic when polling > - using new free_list accessors > - added new dedicated pending_lock to access pending_cmds_list > - fixed a few comments > > Cristian Marussi (8): > firmware: arm_scmi: Add a virtio channel refcount > firmware: arm_scmi: Review virtio free_list handling > firmware: arm_scmi: Add atomic mode support to virtio transport > dt-bindings: firmware: arm,scmi: Add atomic-threshold-us optional > property > firmware: arm_scmi: Support optional system wide atomic-threshold-us > firmware: arm_scmi: Add atomic support to clock protocol > firmware: arm_scmi: Add support for clock_enable_latency > clk: scmi: Support atomic clock enable/disable API > > .../bindings/firmware/arm,scmi.yaml | 10 + > drivers/clk/clk-scmi.c | 71 ++- > drivers/firmware/arm_scmi/Kconfig | 15 + > drivers/firmware/arm_scmi/clock.c | 34 +- > drivers/firmware/arm_scmi/driver.c | 33 +- > drivers/firmware/arm_scmi/virtio.c | 591 +++++++++++++++--- > include/linux/scmi_protocol.h | 9 +- > 7 files changed, 655 insertions(+), 108 deletions(-) > > -- > 2.17.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Fri, Mar 04, 2022 at 11:13:47AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 17, 2022 at 01:12:26PM +0000, Cristian Marussi wrote: > > Hi, > > > > This small series is the tail-subset of the previous V8 series about atomic > > support in SCMI [1], whose 8-patches head-subset has now been queued on > > [2]; as such, it is based on [2] on top of tag scmi-updates-5.17: > > > > commit 94d0cd1da14a ("firmware: arm_scmi: Add new parameter to > > mark_txdone") > > > > Patch [1/8] substitute virtio-scmi ready flag and lock with a reference > > counter to keep track of vio channels lifetime while removing the need of > > a wide spinlocked section (that would cause issues with introduction of > > virtio polling support) > > > > Patch [2/8] adds a few helpers to handle the TX free_list and a dedicated > > spinlock to reduce the reliance on the main one. > > > > Patch [3/8] adds polling mode to SCMI VirtIO transport in order to support > > atomic operations on such transport. > > > > Patches [4,5/8] introduce a new optional SCMI binding, atomic-threshold-us, > > to configure a platform specific time threshold used in the following > > patches to select with a finer grain which SCMI resources should be > > eligible for atomic operations when requested. > > > > Patch [6/8] exposes new SCMI Clock protocol operations to allow an SCMI > > user to request atomic mode on clock enable commands. > > > > Patch [7/8] adds support to SCMI Clock protocol for a new clock attributes > > field which advertises typical enable latency for a specific resource. > > > > Finally patch [8/8] add support for atomic operations to the SCMI clock > > driver; the underlying logic here is that we register with the Clock > > framework atomic-capable clock resources if and only if the backing SCMI > > transport is capable of atomic operations AND the specific clock resource > > has been advertised by the SCMI platform as having: > > > > clock_enable_latency <= atomic-threshold-us > > > > The idea is to avoid costly atomic busy-waiting for resources that have > > been advertised as 'slow' to operate upon. (i.e. a PLL vs a gating clock) > > > > To ease testing the whole series can be find at [3]. > > > > Any feedback/testing welcome as usual. > > > > Thanks, > > Cristian > > > SCMI specific stuff so I don't have anything to add here. > > By the way, it does not look like anything regarding SCMI atomic support > is needed in the virtio spec - is it true the interface with the device > is unaffected? > Yes SCMI atomic uses the existing VirtIO SCMI Device specification and the existing VirtIO common API for polling. The only addition on the implementation side is the polling ABA problem mitigation that I proposed as an addiional mechanism (wrap counters) in the Virtio core with: https://lore.kernel.org/linux-arm-kernel/20220208152520.52983-1-cristian.marussi@arm.com/#r I'll repost soon this latter series about wrap counters on top of the merged SCMI atomic series so as to make use of this mitigation from SCMI while in polling mode. Thanks for the feedback, Cristian