| Message ID | 20211222141342.56395-1-sudeep.holla@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] firmware: arm_scmi: Updates for v5.17 | expand |
Hi again, On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote: > Hi ARM SoC Team, > > Please pull ! > I am aware I sent this pull request just around the same time Arnd finalised the initial set. I have seen emails suggesting that Olof might be planning to merge additional PR, so it would be great if this gets included in that cut. All the changes are in -next since 21st December, so there should be no surprises. Thanks again and sorry for nagging. -- Regards, Sudeep
On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote: > > Hi again, > > On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote: > > Hi ARM SoC Team, > > > > Please pull ! > > > > I am aware I sent this pull request just around the same time Arnd finalised > the initial set. I have seen emails suggesting that Olof might be planning > to merge additional PR, so it would be great if this gets included in > that cut. All the changes are in -next since 21st December, so there should > be no surprises. > > Thanks again and sorry for nagging. Yeah, no worries -- I'd been letting pull requests sitting for a while over the holidays. I've merged this into our late branch now. Thanks, -Olof
On Sat, Jan 8, 2022 at 9:24 PM Olof Johansson <olof@lixom.net> wrote: > On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote: > > On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote: > > > Hi ARM SoC Team, > > > > > > Please pull ! > > > > > > > I am aware I sent this pull request just around the same time Arnd finalised > > the initial set. I have seen emails suggesting that Olof might be planning > > to merge additional PR, so it would be great if this gets included in > > that cut. All the changes are in -next since 21st December, so there should > > be no surprises. > > > > Thanks again and sorry for nagging. > > Yeah, no worries -- I'd been letting pull requests sitting for a while over the > holidays. I've merged this into our late branch now. Hi Sudeep, I'm going through all the stuff that we ended up not getting into v5.17. As you probably already know, this pull request was part of the arm/late branch that missed out, sorry for the mistake on our end. As the contents are still fine, I could offer to either merge the branch again for v5.18, or I can drop it and wait for a new pull request from you, please let me know your preference. If any of the patches are bug fixes that you think should be in v5.17, it would be good to have a separate pull request or patch email for the 5.17 fixes branch. Arnd
On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote: > On Sat, Jan 8, 2022 at 9:24 PM Olof Johansson <olof@lixom.net> wrote: > > On Fri, Jan 07, 2022 at 11:37:40AM +0000, Sudeep Holla wrote: > > > On Wed, Dec 22, 2021 at 02:13:42PM +0000, Sudeep Holla wrote: > > > > Hi ARM SoC Team, > > > > > > > > Please pull ! > > > > > > > > > > I am aware I sent this pull request just around the same time Arnd finalised > > > the initial set. I have seen emails suggesting that Olof might be planning > > > to merge additional PR, so it would be great if this gets included in > > > that cut. All the changes are in -next since 21st December, so there should > > > be no surprises. > > > > > > Thanks again and sorry for nagging. > > > > Yeah, no worries -- I'd been letting pull requests sitting for a while over the > > holidays. I've merged this into our late branch now. > > Hi Sudeep, > > I'm going through all the stuff that we ended up not getting into v5.17. > As you probably already know, this pull request was part of the arm/late > branch that missed out, sorry for the mistake on our end. > No worries, it was indeed a late PR. > As the contents are still fine, I could offer to either merge the branch again > for v5.18, or I can drop it and wait for a new pull request from you, please > let me know your preference. > Is it OK if I merge this tag with v5.17-rc1 as base and load it with any new v5.18 material on the top ? I just want to avoid rebasing as the same time some of the new material depend on these changes. Let me know if that is fine. I am open to any other suggestions too. > If any of the patches are bug fixes that you think should be in v5.17, > it would be good to have a separate pull request or patch email for the > 5.17 fixes branch. > Sure, I will check again, but AFAIK there were no fixes for existing bugs.
On Tue, Feb 8, 2022 at 11:33 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote: > > As the contents are still fine, I could offer to either merge the branch again > > for v5.18, or I can drop it and wait for a new pull request from you, please > > let me know your preference. > > > > Is it OK if I merge this tag with v5.17-rc1 as base and load it with any > new v5.18 material on the top ? I just want to avoid rebasing as the same time > some of the new material depend on these changes. Let me know if that > is fine. I am open to any other suggestions too. Yes, I think that is ok, as long as you start a branch from v5.17-rc1 and merge the old contents into the new branch, rather than back-merging the -rc1 tag into your existing branch. This way, the git history still makes sense across the merges. Arnd
On Tue, Feb 08, 2022 at 12:14:25PM +0100, Arnd Bergmann wrote: > On Tue, Feb 8, 2022 at 11:33 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Tue, Feb 08, 2022 at 11:00:43AM +0100, Arnd Bergmann wrote: > > > As the contents are still fine, I could offer to either merge the branch again > > > for v5.18, or I can drop it and wait for a new pull request from you, please > > > let me know your preference. > > > > > > > Is it OK if I merge this tag with v5.17-rc1 as base and load it with any > > new v5.18 material on the top ? I just want to avoid rebasing as the same time > > some of the new material depend on these changes. Let me know if that > > is fine. I am open to any other suggestions too. > > Yes, I think that is ok, as long as you start a branch from v5.17-rc1 and merge > the old contents into the new branch, rather than back-merging the -rc1 tag > into your existing branch. This way, the git history still makes sense > across the merges. Thanks for confirming my understanding.
Hi ARM SoC Team, Please pull ! Regards, Sudeep -->8 The following changes since commit 026d9835b62bba34b7e657a0bfb76717822f9319: firmware: arm_scmi: Fix type error assignment in voltage protocol (2021-11-17 11:24:50 +0000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.17 for you to fetch changes up to 94d0cd1da14af0042c8ee7c2cf401dfc321c575c: firmware: arm_scmi: Add new parameter to mark_txdone (2021-12-21 10:59:38 +0000) ---------------------------------------------------------------- Arm SCMI firmware interface updates for v5.17 Couple of main additions: - Support for OPTEE based SCMI transport to enable using SCMI service provided by OPTEE on some platforms - Support for atomic SCMI transports which enables few SCMI transactions to be completed in atomic context. This involves other refactoring work associated with it. It also marks SMC and OPTEE as atomic transport as the commands are completed once the return Other changes involves some trace and log enhancements and a miscellaneous bug fix. ---------------------------------------------------------------- Cristian Marussi (15): firmware: arm_scmi: Review some virtio log messages firmware: arm_scmi: Make virtio Version_1 compliance optional firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms firmware: arm_scmi: Refactor message response path include: trace: Add new scmi_xfer_response_wait event firmware: arm_scmi: Use new trace event scmi_xfer_response_wait firmware: arm_scmi: Add configurable polling mode for transports firmware: arm_scmi: Make smc transport use common completions firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret firmware: arm_scmi: Add support for atomic transports firmware: arm_scmi: Add atomic mode support to smc transport firmware: arm_scmi: Add new parameter to mark_txdone Etienne Carriere (2): dt-bindings: arm: Add OP-TEE transport for SCMI firmware: arm_scmi: Add optee transport Sudeep Holla (1): firmware: arm_scmi: optee: Drop the support for the OPTEE shared dynamic buffer Wei Yongjun (1): firmware: arm_scmi: optee: Fix missing mutex_init() .../devicetree/bindings/firmware/arm,scmi.yaml | 65 +++ drivers/firmware/arm_scmi/Kconfig | 41 ++ drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/common.h | 26 +- drivers/firmware/arm_scmi/driver.c | 207 ++++++-- drivers/firmware/arm_scmi/mailbox.c | 3 +- drivers/firmware/arm_scmi/optee.c | 567 +++++++++++++++++++++ drivers/firmware/arm_scmi/smc.c | 98 +++- drivers/firmware/arm_scmi/virtio.c | 22 +- include/linux/scmi_protocol.h | 8 + include/trace/events/scmi.h | 28 + 11 files changed, 986 insertions(+), 80 deletions(-) create mode 100644 drivers/firmware/arm_scmi/optee.c