| Message ID | 20230718160833.36397-1-quic_nkela@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add qcom hvc/shmem transport | expand |
On 18.07.2023 18:08, Nikunj Kela wrote: > This change introduce a new transport channel for Qualcomm virtual > platforms. The transport is mechanically similar to ARM_SCMI_TRANSPORT_SMC. > The difference between the two transports is that a parameter is passed in > the hypervisor call to identify which doorbell to assert. This parameter is > dynamically generated at runtime on the device and insuitable to pass via > the devicetree. > > The function ID and parameter are stored by firmware in the shmem region. > > This has been tested on ARM64 virtual Qualcomm platform. What can we test it on? Konrad
On 9/7/2023 9:16 AM, Konrad Dybcio wrote: > On 18.07.2023 18:08, Nikunj Kela wrote: >> This change introduce a new transport channel for Qualcomm virtual >> platforms. The transport is mechanically similar to ARM_SCMI_TRANSPORT_SMC. >> The difference between the two transports is that a parameter is passed in >> the hypervisor call to identify which doorbell to assert. This parameter is >> dynamically generated at runtime on the device and insuitable to pass via >> the devicetree. >> >> The function ID and parameter are stored by firmware in the shmem region. >> >> This has been tested on ARM64 virtual Qualcomm platform. > What can we test it on? > > Konrad This is being developed for SA8775p platform.
This change augments smc transport to include support for Qualcomm virtual
platforms by passing a parameter(capability-id) in the hypervisor call to
identify which doorbell to assert. This parameter is dynamically generated
at runtime on the device and insuitable to pass via the devicetree.
The function ID and parameter are stored by firmware in the shmem region.
This has been tested on ARM64 virtual Qualcomm platform.
---
v4 -> port the changes into smc.c
v3 -> fix the compilation error reported by the test bot,
add support for polling based instances
v2 -> use allOf construct in dtb schema,
remove wrappers from mutexes,
use architecture independent channel layout
v1 -> original patches
Nikunj Kela (4):
firmware: arm_scmi: Add polling support for completion in smc
dt-bindings: arm: convert nested if-else construct to allOf
dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI
firmware: arm_scmi: Add qcom hvc/shmem transport support
.../bindings/firmware/arm,scmi.yaml | 67 +++++++++++--------
drivers/firmware/arm_scmi/Kconfig | 14 ++++
drivers/firmware/arm_scmi/driver.c | 1 +
drivers/firmware/arm_scmi/smc.c | 62 +++++++++++++++--
4 files changed, 110 insertions(+), 34 deletions(-)
Gentle Ping! On 9/11/2023 12:43 PM, Nikunj Kela wrote: > This change augments smc transport to include support for Qualcomm virtual > platforms by passing a parameter(capability-id) in the hypervisor call to > identify which doorbell to assert. This parameter is dynamically generated > at runtime on the device and insuitable to pass via the devicetree. > > The function ID and parameter are stored by firmware in the shmem region. > > This has been tested on ARM64 virtual Qualcomm platform. > > --- > v4 -> port the changes into smc.c > > v3 -> fix the compilation error reported by the test bot, > add support for polling based instances > > v2 -> use allOf construct in dtb schema, > remove wrappers from mutexes, > use architecture independent channel layout > > v1 -> original patches > > Nikunj Kela (4): > firmware: arm_scmi: Add polling support for completion in smc > dt-bindings: arm: convert nested if-else construct to allOf > dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI > firmware: arm_scmi: Add qcom hvc/shmem transport support > > .../bindings/firmware/arm,scmi.yaml | 67 +++++++++++-------- > drivers/firmware/arm_scmi/Kconfig | 14 ++++ > drivers/firmware/arm_scmi/driver.c | 1 + > drivers/firmware/arm_scmi/smc.c | 62 +++++++++++++++-- > 4 files changed, 110 insertions(+), 34 deletions(-) >
On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: > Gentle Ping! > I will take a look at this later this week. That said, I am unable be gauge the urgency based on you ping here. You have shown the same urgency last time for a feature that I queued promptly just to know that it was abandon within couple of days. So I don't want to rush here simply based on the number of pings here. I need to understand that it is really that important. For now, I am thinking of skipping even v6.7 just to allow some time for Qcom to make up its mind and be absolutely sure this is what they *really* want this time.
On Mon, Sep 18, 2023 at 04:15:52PM +0100, Sudeep Holla wrote: > On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: > > Gentle Ping! > > > > I will take a look at this later this week. That said, I am unable be > gauge the urgency based on you ping here. You have shown the same urgency > last time for a feature that I queued promptly just to know that it was > abandon within couple of days. So I don't want to rush here simply based > on the number of pings here. I need to understand that it is really that > important. For now, I am thinking of skipping even v6.7 just to allow > some time for Qcom to make up its mind and be absolutely sure this is what > they *really* want this time. Hi Sudeep, Red Hat is interested in this patch set. Qualcomm is moving one of their automotive platforms over to use SCMI and this will appear in that product. Brian
On 18/09/2023 17:01, Nikunj Kela wrote:
> Gentle Ping!
Whatever is written with exclamation mark is not really gentle.
Especially for second time... and 7 days after posting. 7 days and you ping.
Please relax, and help out by reviewing other patches on the mailing
lists in order to relieve the burden of maintainers and move your
patches higher up the list.
Best regards,
Krzysztof
On Mon, Sep 18, 2023 at 11:54:25AM -0400, Brian Masney wrote: > On Mon, Sep 18, 2023 at 04:15:52PM +0100, Sudeep Holla wrote: > > On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: > > > Gentle Ping! > > > > > > > I will take a look at this later this week. That said, I am unable be > > gauge the urgency based on you ping here. You have shown the same urgency > > last time for a feature that I queued promptly just to know that it was > > abandon within couple of days. So I don't want to rush here simply based > > on the number of pings here. I need to understand that it is really that > > important. For now, I am thinking of skipping even v6.7 just to allow > > some time for Qcom to make up its mind and be absolutely sure this is what > > they *really* want this time. > > Hi Sudeep, > > Red Hat is interested in this patch set. Qualcomm is moving one of their > automotive platforms over to use SCMI and this will appear in that > product. > Thanks Brian, I trust Redhat over Qcom
On 9/19/2023 1:56 AM, Sudeep Holla wrote: > On Mon, Sep 18, 2023 at 11:54:25AM -0400, Brian Masney wrote: >> On Mon, Sep 18, 2023 at 04:15:52PM +0100, Sudeep Holla wrote: >>> On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: >>>> Gentle Ping! >>>> >>> I will take a look at this later this week. That said, I am unable be >>> gauge the urgency based on you ping here. You have shown the same urgency >>> last time for a feature that I queued promptly just to know that it was >>> abandon within couple of days. So I don't want to rush here simply based >>> on the number of pings here. I need to understand that it is really that >>> important. For now, I am thinking of skipping even v6.7 just to allow >>> some time for Qcom to make up its mind and be absolutely sure this is what >>> they *really* want this time. >> Hi Sudeep, >> >> Red Hat is interested in this patch set. Qualcomm is moving one of their >> automotive platforms over to use SCMI and this will appear in that >> product. >> > Thanks Brian, I trust Redhat over Qcom
On Mon, Oct 02, 2023 at 10:31:27AM -0700, Nikunj Kela wrote: > > On 9/19/2023 1:56 AM, Sudeep Holla wrote: > > On Mon, Sep 18, 2023 at 11:54:25AM -0400, Brian Masney wrote: > > > On Mon, Sep 18, 2023 at 04:15:52PM +0100, Sudeep Holla wrote: > > > > On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: > > > > > Gentle Ping! > > > > > > > > > I will take a look at this later this week. That said, I am unable be > > > > gauge the urgency based on you ping here. You have shown the same urgency > > > > last time for a feature that I queued promptly just to know that it was > > > > abandon within couple of days. So I don't want to rush here simply based > > > > on the number of pings here. I need to understand that it is really that > > > > important. For now, I am thinking of skipping even v6.7 just to allow > > > > some time for Qcom to make up its mind and be absolutely sure this is what > > > > they *really* want this time. > > > Hi Sudeep, > > > > > > Red Hat is interested in this patch set. Qualcomm is moving one of their > > > automotive platforms over to use SCMI and this will appear in that > > > product. > > > > > Thanks Brian, I trust Redhat over Qcom
On Mon, Oct 02, 2023 at 10:31:27AM -0700, Nikunj Kela wrote: > > On 9/19/2023 1:56 AM, Sudeep Holla wrote: > > On Mon, Sep 18, 2023 at 11:54:25AM -0400, Brian Masney wrote: > > > On Mon, Sep 18, 2023 at 04:15:52PM +0100, Sudeep Holla wrote: > > > > On Mon, Sep 18, 2023 at 08:01:26AM -0700, Nikunj Kela wrote: > > > > > Gentle Ping! > > > > > > > > > I will take a look at this later this week. That said, I am unable be > > > > gauge the urgency based on you ping here. You have shown the same urgency > > > > last time for a feature that I queued promptly just to know that it was > > > > abandon within couple of days. So I don't want to rush here simply based > > > > on the number of pings here. I need to understand that it is really that > > > > important. For now, I am thinking of skipping even v6.7 just to allow > > > > some time for Qcom to make up its mind and be absolutely sure this is what > > > > they *really* want this time. > > > Hi Sudeep, > > > > > > Red Hat is interested in this patch set. Qualcomm is moving one of their > > > automotive platforms over to use SCMI and this will appear in that > > > product. > > > > > Thanks Brian, I trust Redhat over Qcom