- 13 May, 2020 11 commits
-
-
Cristian Marussi authored
[HACK][DEBUG] SCMI IIOdev example driver Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com>
-
Cristian Marussi authored
SCMI v2.1 Sensor Extensions support - new tentative API - new internal structs for msg resp and notific - new Sensor notification support - new v2.1 sensor descriptor axis and update_intervals handling - new protocol init and ops with v1 and v2 coexistence - new config set/get - new reading_timestamped - added new sensor classes enums Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com>
-
Cristian Marussi authored
Make SCMI Base protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V6 --> V7 - fixed report.timestamp type - fix max_payld_sz initialization - fix report layout and initialization - expose SCMI_EVENT_ in linux/scmi_protocol.h V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed unsual return construct V3 --> V4 - scmi_event field renamed V2 --> V3 - added handle awareness V1 --> V2 - simplified .set_notify_enabled() implementation moving the ALL_SRCIDs logic out of protocol. ALL_SRCIDs logic is now in charge of the notification core, together with proper reference counting of enables - switched to devres protocol-registration
-
Cristian Marussi authored
Make SCMI Reset protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V6 --> V7 - fixed report.timestamp type - added agent_id notification field - fixed .max_payld_sz initialization - expose SCMI_EVENT_ in linux/scmi_protocol.h V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed unsual return construct V3 --> V4 - scmi_event field renamed V2 --> V3 - added handle awareness V1 --> V2 - simplified .set_notify_enabled() implementation moving the ALL_SRCIDs logic out of protocol. ALL_SRCIDs logic is now in charge of the notification core, together with proper reference counting of enables - switched to devres protocol-registration
-
Cristian Marussi authored
Make SCMI Sensor protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V6 --> V7 - fixed report.timestamp type - removed trip_point_notify from .sensor_ops - fixed max_payld_sz initialization - expose SCMI_EVENT_ in linux/scmi_protocol.h V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed unsual return construct V3 --> V4 - scmi_event field renamed V2 --> V3 - added handle awareness V1 --> V2 - simplified .set_notify_enabled() implementation moving the ALL_SRCIDs logic out of protocol. ALL_SRCIDs logic is now in charge of the notification core, together with proper reference counting of enables - switched to devres protocol-registration
-
Cristian Marussi authored
Make SCMI Perf protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V6 --> V7 - fixed report.timestamp type - fixed max_payld_sz initialization - expose SCMI_EVENT_ in linux/scmi_protocol.h V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed unsual return construct V3 --> V4 - scmi_event field renamed V2 --> V3 - added handle awareness V1 --> V2 - simplified .set_notify_enabled() implementation moving the ALL_SRCIDs logic out of protocol. ALL_SRCIDs logic is now in charge of the notification core, together with proper reference counting of enables - switched to devres protocol-registration
-
Cristian Marussi authored
Make SCMI Power protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V6 --> V7 - fixed report.timestamp type - removed POWER_STATE_CHANGE_REQUESTED motification handling (deprecated) - fixed max_payld_sz initialization - expose SCMI_EVENT_ in linux/scmi_protocol.h V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed unsual return construct V3 --> V4 - scmi_event field renamed V2 --> V3 - added handle awareness V1 --> V2 - simplified .set_notify_enabled() implementation moving the ALL_SRCIDs logic out of protocol. ALL_SRCIDs logic is now in charge of the notification core, together with proper reference counting of enables - switched to devres protocol-registration
-
Cristian Marussi authored
Initialize and enable SCMI Notifications core support during bus/driver probe phase, so that protocols can start registering their supported events during their initialization. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V3 --> V4 - simplified core initialization: protocols events' registrations is now disjoint from users' callback registrations, so that events' generation can be enabled earlier for registered events and delayed for pending ones in order to support deferred (or missing) protocol initialization V2 --> V3 - reviewed core initialization: all implemented protocols must complete their protocol-events registration phases before notifications can be enabled as a whole; in the meantime any user's callback registration requests possibly issued while the notifications were not enabled remain pending: a dedicated worker completes the handlers registration once all protocols have been initialized. NOTE THAT this can lead to ISSUES with late inserted or missing SCMI modules (i.e. for protocols defined in the DT and implemented by the platform but lazily loaded or not loaded at all.), since in these scenarios notifications dispatching will be enabled later or never. - reviewed core exit: protocol users (devices) are accounted on probe/ remove, and protocols' events are unregisteredonce last user go (can happen only at shutdown) V1 --> V2 - added timestamping - moved notification init/exit and using devres
-
Cristian Marussi authored
Add core SCMI Notifications dispatch and delivery support logic which is able, at first, to dispatch well-known received events from the RX ISR to the dedicated deferred worker, and then, from there, to final deliver the events to the registered users' callbacks. Dispatch and delivery is just added here, still not enabled. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V7 --> V8 - Fixed enabled check in scmi_notify() not to use atomics V5 --> V6 - added handle argument to fill_custom_report() V4 --> V5 - fixed kernel-doc - fixed unneded var initialization V3 --> V4 - dispatcher now handles dequeuing of events in chunks (header+payload): handling of these in_flight events let us remove one unneeded memcpy on RX interrupt path (scmi_notify) - deferred dispatcher now access their own per-protocol handlers' table reducing locking contention on the RX path V2 --> V3 - exposing wq in sysfs via WQ_SYSFS V1 --> V2 - splitted out of V1 patch 04 - moved from IDR maps to real HashTables to store event_handlers - simplified delivery logic
-
Cristian Marussi authored
Add core SCMI Notifications callbacks-registration support: allow users to register their own callbacks against the desired events. Whenever a registration request is issued against a still non existent event, mark such request as pending for later processing, in order to account for possible late initializations of SCMI Protocols associated to loadable drivers. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V7 --> V8 - Fixed init check, un-needed atomics removed V6 --> V7 - removed un-needed ktime.h include V4 --> V5 - fix kernel-doc - reviewed REVT_NOTIFY_ENABLE macro - added matching barrier for late_init V3 --> V4 - split registered_handlers hashtable on a per-protocol basis to reduce unneeded contention - introduced pending_handlers table and related late_init worker to finalize handlers registration upon effective protocols' registrations - introduced further safe accessors macros for registered_protocols and registered_events arrays V2 --> V3 - refactored get/put event_handler - removed generic non-handle-based API V1 --> V2 - splitted out of V1 patch 04 - moved from IDR maps to real HashTables to store event_handlers - added proper enable_events refcounting via __scmi_enable_evt() [was broken in V1 when using ALL_SRCIDs notification chains] - reviewed hashtable cleanup strategy in scmi_notifications_exit() - added scmi_register_event_notifier()/scmi_unregister_event_notifier() to include/linux/scmi_protocol.h as a candidate user API [no EXPORTs still] - added notify_ops to handle during initialization as an additional internal API for scmi_drivers
-
Cristian Marussi authored
Add core SCMI Notifications protocol-registration support: allow protocols to register their own set of supported events, during their initialization phase. Notification core can track multiple platform instances by their handles. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> --- V7 --> V8 - Fixed init/enable procedure, un-needed atomics removed V4 --> V5 - fixed kernel-doc - added barriers for registered protocols and events - using kfifo_alloc and devm_add_action_or_reset V3 --> V4 - removed scratch ISR buffer, move scratch BH buffer into protocol descriptor - converted registered_protocols and registered_events from hashtables into bare fixed-sized arrays - removed unregister protocols' routines (never called really) V2 --> V3 - added scmi_notify_instance to track target platform instance V1 --> V2 - splitted out of V1 patch 04 - moved from IDR maps to real HashTables to store events - scmi_notifications_initialized is now an atomic_t - reviewed protocol registration/unregistration to use devres - fixed: drivers/firmware/arm_scmi/notify.c:483:18-23: ERROR: reference preceded by free on line 482 Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@lip6.fr>
-
- 21 Apr, 2020 8 commits
-
-
Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
It's sometimes useful to identify the mailbox controller with the name as specified in the devicetree via mbox-name property especially in a system with multiple controllers. This patch adds support to read and record the mailbox controller name. Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
We now have the basic infrastructure and binding to support doorbells on ARM MHU controller. This patch adds all the necessary mailbox operations to add support for the doorbells. Maximum of 32 doorbells are supported on each physical channel, however the total number of doorbells is restricted to 20 in order to save memory. It can increased if required in future. Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
In order to support doorbells, we need a bit of reword around data structures that are per-channel. Since the number of doorbells are not fixed though restricted to maximum of 20, the channel assignment and initialization is move to xlate function. This patch also adds the platform data for the existing support of one channel per physical channel. Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
In preparation to introduce support for doorbells which require the interrupt handlers to be threaded, this patch moves the existing interrupt handler to threaded handler. Also it moves out the registering and freeing of the handlers from the mailbox startup and shutdown methods. This also is required to support doorbells. Cc: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
The ARM MHU has mechanism to assert interrupt signals to facilitate inter-processor message based communication. It drives the signal using a 32-bit register, with all 32-bits logically ORed together. It also enables software to set, clear and check the status of each of the bits of this register independently. Each bit of the register can be associated with a type of event that can contribute to raising the interrupt thereby allowing it to be used as independent doorbells. Since the first version of this binding can't support doorbells, this patch extends the existing binding to support them by allowing "#mbox-cells" to be 2. Cc: Jassi Brar <jaswinder.singh@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Some mailbox controllers are lack FIFOs or memory to transmit data. They typically contains single doorbell registers to just signal the remote. The actually data is transmitted/shared using some shared memory which is not part of the mailbox. Such controllers don't need to transmit any data, they just transmit the signal. In such controllers the data pointer passed to mbox_send_message is passed to client via it's tx_prepare callback. Controller doesn't need any data to be passed from the client. This patch introduce the new API send_signal to support such doorbell/ signal mode in mailbox controllers. This is useful to avoid another layer of abstraction as typically multiple channels can be multiplexied into single register. Cc: Jassi Brar <jassisinghbrar@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
- 20 Apr, 2020 5 commits
-
-
Sudeep Holla authored
SMCCC can return NOT_SUPPORTED(-1). Map it to appropriate Linux error codes namely -EOPNOTSUPP. Link: https://lore.kernel.org/r/20200417103232.6896-1-sudeep.holla@arm.com Reported-and-Tested-by:
: Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by:
Etienne Carriere <etienne.carriere@linaro.org> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Upon reception of an unexpected bogus delayed response, clear the channel and bail-out safely. Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com Fixes: 4d09852b ("firmware: arm_scmi: Add support for notifications message processing") Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Clear channel properly when done processing a delayed response. This will let the platform firmware know that the channel is now free to use it for any new delayed response or notification. Link: https://lore.kernel.org/r/20200420152315.21008-4-cristian.marussi@arm.com Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> (sudeep.holla: Updated commit log to reflect that channel is now free for platform to use) Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
When an unexpected response message is received we currently warn the user and bail-out, ensure to also free the channel by invoking the transport independent operation .clear_channel() Link: https://lore.kernel.org/r/20200420152315.21008-3-cristian.marussi@arm.com Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
SCMI transport operation .clear_notification() is indeed a generic method to clear the channel in a transport dependent way, as such it could be a useful helper also in other contexts. Rename such method as .clear_channel(), renaming accordingly also its already existent call-sites. No functional change. Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
- 14 Apr, 2020 12 commits
-
-
Sudeep Holla authored
Add the mechanisms to distinguish notifications from delayed responses and command responses. Also add support to properly fetch notification messages upon reception. Notifications processing does not continue any further after the fetch phase. Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> [Reworked/renamed scmi_handle_xfer_delayed_resp()] Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Add common transport-layer methods to: - fetch a notification instead of a response - clear a pending notification Add also all the needed support in mailbox/shmem transports. Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
Add commands' enumerations and messages definitions for all existing notify-enable commands across all protocols. Link: https://lore.kernel.org/r/20200327143438.5382-3-cristian.marussi@arm.com Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
With all the plumbing in place, let's just add the separate dedicated receive buffers to handle notifications that can arrive asynchronously from the platform firmware to OS. Also add one check to see if the platform supports any receive channels before allocating the receive buffers: since those buffers are optionally supported though, the whole xfer initialization is also postponed to be able to check for their existence in advance. Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> [Changed parameters in __scmi_xfer_info_init()] Signed-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
If this header is include twice, it will generate loads of compile time error with the following below error pattern. It was reported by 0day kbuild robot on a branch pushed with double inclusion by accident. This is based on the similar change in linux/scmi_protocol.h error: conflicting types for ‘...’ note: previous declaration of ‘...’ was here error: redefinition of ‘...’ Add a header include guard just in case. Link: https://lore.kernel.org/r/20200403171018.1230-2-sudeep.holla@arm.com Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
If this header is include twice, it will generate loads of compile time error with the following below error pattern. It was reported by 0day kbuild robot on a branch pushed with double inclusion by accident. error: conflicting types for ‘...’ note: previous declaration of ‘...’ was here error: redefinition of ‘...’ Add a header include guard just in case. Link: https://lore.kernel.org/r/20200403171018.1230-1-sudeep.holla@arm.com Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
The scmi protocol core driver checks for the channel availability before evaluating the shmem property. If the individual protocols don't have separate channel assigned to them, the channel alloted for the BASE protocol is reused automatically. Therefore there is no need to check for the shmem property in the parent node if it is absent in the child protocol node. Link: https://lore.kernel.org/r/20200327163654.13389-5-sudeep.holla@arm.com Tested-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
Instead of declaring the channel availabilty unconditionally, let us check for the presence of "shmem" property and return the channel availablity accordingly. Link: https://lore.kernel.org/r/20200327163654.13389-4-sudeep.holla@arm.com Tested-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
The scmi protocol core driver check for non NULL mark_txdone before invoking the same. There is no need to provide a empty stub. SMC/HVC calls are synchronous and the call return indicates the completion. Link: https://lore.kernel.org/r/20200327163654.13389-3-sudeep.holla@arm.com Tested-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Sudeep Holla authored
In order to support multiple SMC/HVC transport channels with associated shared memory, it is better to maintain the mutex per channel instead of existing global one. Move the smc_mutex into the scmi_smc structure and also rename it to shmem_lock which is more appropriate for it's use. Link: https://lore.kernel.org/r/20200327163654.13389-2-sudeep.holla@arm.com Tested-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
Use the value of "arm,smc-id" property from the device tree as the first argument for SMCCC call leaving all the other arguments as zero for now. There is no Rx, only Tx because of smc/hvc not support Rx. Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com Signed-off-by:
Peng Fan <peng.fan@nxp.com> [sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build] Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
SCMI could use SMC/HVC as tranports. Since there is no standardized SMC/HVC function identifier for the same, we need to use vendor specific id. Add the same into the devicetree binding document. Also add arm,scmi-smc compatible string for smc/hvc transport Link: https://lore.kernel.org/r/1583673879-20714-2-git-send-email-peng.fan@nxp.com Signed-off-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> [sudeep.holla: reworded commit log and subject] Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com>
-
- 12 Apr, 2020 4 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
This sorts the actual field names too, potentially causing even more chaos and confusion at merge time if you have edited the MAINTAINERS file. But the end result is a more consistent layout, and hopefully it's a one-time pain minimized by doing this just before the -rc1 release. This was entirely scripted: ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order Requested-by:
Joe Perches <joe@perches.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
They are all supposed to be sorted, but people who add new entries don't always know the alphabet. Plus sometimes the entry names get edited, and people don't then re-order the entry. Let's see how painful this will be for merging purposes (the MAINTAINERS file is often edited in various different trees), but Joe claims there's relatively few patches in -next that touch this, and doing it just before -rc1 is likely the best time. Fingers crossed. This was scripted with /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS but then I also ended up manually upper-casing a few entry names that stood out when looking at the end result. Requested-by:
Joe Perches <joe@perches.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A set of three patches to fix the fallout of the newly added split lock detection feature. It addressed the case where a KVM guest triggers a split lock #AC and KVM reinjects it into the guest which is not prepared to handle it. Add proper sanity checks which prevent the unconditional injection into the guest and handles the #AC on the host side in the same way as user space detections are handled. Depending on the detection mode it either warns and disables detection for the task or kills the task if the mode is set to fatal" * tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest KVM: x86: Emulate split-lock access as a write in emulator x86/split_lock: Provide handle_guest_split_lock()
-