- 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 authored
Make SCMI Base protocol register with the notification core. Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Cristian Marussi authored
Make SCMI Reset protocol register with the notification core. Reviewed-by:
-
Cristian Marussi authored
Make SCMI Sensor protocol register with the notification core. Reviewed-by:
-
Cristian Marussi authored
Make SCMI Perf protocol register with the notification core. Reviewed-by:
-
Cristian Marussi authored
Make SCMI Power protocol register with the notification core. Reviewed-by:
-
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:
-
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:
-
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:
-
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:
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:
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:
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:
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:
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:
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:
Viresh Kumar <viresh.kumar@linaro.org> 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:
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:
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: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:
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:
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:
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:
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:
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:
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:
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:
-
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()
-
